A couple of months ago I posted a short article regarding interoperability between Java and Groovy. In it, I discussed the “chicken and egg dependency problem,” wherein a circular dependency between Java code and Groovy code makes it difficult to get either portion compiled:
What, then, is the solution? Well, we would probably need to use a single compiler (or compiler framework) for both languages. Classes defined in Java syntax would need to be aware of classes defined in Groovy syntax, and vice versa, before any bytecode is serialized into .class files… Given that Sun GPL’ed the Java compiler not too long ago, it doesn’t seem too far-fetched to wonder if someone from Groovy, JRuby, Jython or Rhino might not start exploring the possibilities.
Well, it looks like the good folks at JetBrains have taken a stab at exactly this sort of integration, and the resultant joint Java/Groovy compiler will be included in the main Groovy distribution starting with version 1.1-beta-2. I have to say, I think this is a brilliant move on the part of JetBrains. I’m guessing that Alex Tkachman (the source of the patch) probably enjoyed tinkering on this enough that he worked on it in his spare time, and the goodwill generated by this move has got to be tremendous.
Political and economic concerns aside, the detailed technical description provided by Jochen Theodorou makes for interesting reading. My first impression is that this implementation is not the optimal solution — the short synopsis is that the Groovy compiler creates temporary bytecode stubs for the Groovy classes, feeds these stubs to the Java compiler so that it doesn’t barf all over the place, and then comes back and replaces the stubs with real bytecode.
It is, however, probably the best solution that can be achieved short of overcoming the final bastion of JVM monolinguism: javac itself. Because once Sun agrees to modify the Java compiler such that it becomes a framework for pluggable compiler components, multiple first-class languages on the JVM will have become a reality. You’ll be able to write your string utility methods in Ruby — and take advantage of it’s great regex support. You’ll be able to write your data export functions in Groovy — and take advantage of the great Scriptom library. You’ll also be able to continue to write code in Java — all without artificial abstractions getting in the way.
The point is that you’ll be able to make the decision on a case-by-case basis, rather than project-by-project. Further, your decision won’t be colored by the decisions others made while implementing the libraries you depend upon. It’s gonna be sweet!
