« Griffon 0.1 Beta Released | Main | Groovy Console Bling-Bling »

Griffon <3's Java

When I first started poking around the Groovy project one of the things I didn't get was the whole MOP thing. Why did every method have to go through the MOP? I thought it was the boat anchor that was going to sink the ship. However, the more I dug into Builders, method injection, closures and delegates, properties, and in general all of the other neat stuff that Groovy does the more I saw that to some extent all of them were enabled by the MOP. Even closures use the MOP, mundane things like trying to figure out where a method call should be dispatched to (the declaring class or some delegate that has been assigned?) uses the MOP. In a sense the MOP is the boat anchor that steadies the language in unpredictable waters.

About the same time I came to my senses about the MOP something wonderful was donated to the Groovy project from the people over at IntelliJ (the IDE that eclipsed my 7 year love affair with NetBeans). They donated a joint Java/Groovy compiler. The Groovy/Java interop story was always very simple. In fact it is so simple an intern could do it. Well, not just any intern. Er... Umm... actually... well... any intern that could fire up two different compilers from the command line could do it. The new joint compiler fixed that, so that any intern who could fire up one compiler could do the interop. The compiler part was really the only hard part because the code looked the same in Groovy and Java, as if you are calling another object of the same language. And at the JVM level the code was the same, following the same naming semantics as Java. However, if any of your interns get a little too excited when you mention a joint compiler and you are thinking of hiring them after the internship, you may want to check with HR to see if there are any policies that they may be concerned about. Some HR departments may be OK with that intern. But be sure to check, you know, for the intern's sake.

So how do those two different threads tie into Griffon? When I first started laying down code for Griffon I intentionally merged the Java and Groovy source trees in the griffon-app. Grails has seperate directory forks in some places for Java and Groovy, of course those decisions were made before the joint compiler was integrated into Groovy. But since I was starting with joint compilation being available, there was every reason to turn it on. And it's turned on everywhere. You could write your controller and models in Java if you wanted to (sounds like a blog post there..) and place the code in the same directories, and it will just magically work.

So when would you want to write code in Java in a Griffon project? First, you would never need to write it to interop with an external java library. Groovy integrates seamlessly with them. In fact, all those snazzy plugins Andres has been chugging out are (for the most part) wrappers for existing Java libraries, packaged into groovy bits for easy use by Griffon. But back to the original question, you would want to write Java (a) if you are more comfortable with it, but it won't take you long to see how easy coding in Groovy is; or (b) if you observe performance issues relating to processor load.

There are two key caveats in the (b) case, (i) observe and (ii) processor load. Why wait until you observe a problem? It has been said that premature optimization the root of all evil. I like to think of it instead in terms of time, it takes you time to optimize code that really isn't causing a problem. When you observe performance problems then you know your work will add value. But before then you are just guessing. Since Griffon aims to improve developer productivity for Swing apps working on unsure optimizations defeats that goal. The other key caveat is processor load. There are many performance issues that really are threading and EDT issues. If you are doing a long calculations you should move it to a SwingWorker or other thread off of the GUI thread. If you are locking on objects... don't. Dropping down to Java won't fix lock contention. Re-think what you are doing and leave data that can be read without locking. And if you are doing database calls in the EDT... let me check with HR before I write up any job offers.


This page contains a single entry from the blog posted on January 2, 2009 9:54 PM.

The previous post in this blog was Griffon 0.1 Beta Released.

The next post in this blog is Groovy Console Bling-Bling.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.33