Almost to years ago I’ve invented and then wrote joint compiler for Groovy and Java. The idea was pretty simple – we do compilation in 3 steps
1) Generate Java stubs from Groovy sources
2) Compile all Java code with generated stubs
3) Compile Groovy code with already compiled Java classes

First implementation was done as part of IntelliJ and later another one was written to contribute in Groovy compiler infrastructure. Thanks a lot to Jochen and other guys who improved and incorporated it in to groovyc and ant tasks. It became probably last cornerstone for 100% interoperability between Groovy and Java and now understood by everybody as natural as if it was in Groovy from day one.

But now my arsenal includes Scala as well. Obviously I want to have Groovy and Scala and of course Java together. Isn’t it natural wish?

Fortunately scala compiler is smart as well and knows how to do joint compilation with Java. Scala does it a bit differently than Groovy – by parsing Java source during Java compilation. So the process looks like following
1) Compile Scala code using Java sources on the way
2) Compile Java sources using already compiled scala classes

Unfortunally (but not surprisingly) scala has no clue about Groovy.

Today I realized that the small modification of my original algorythm + scala compiler can create joint compiler for all three languages together. The complete algorithm is following
1) Generate Java stubs from Groovy sources
2) Compile Scala code using Java sources and generated stubs on the way
3) Compile all Java code with generated stubs and compiled Scala classes
4) Compile Groovy code with already compiled Java classes

I believe you will not be surprised that when I knew what I want to do it was pretty easy to implement. In fact it was mostly refactoring of what we did before. So now in my working copy I can compile Groovy+Java+Scala together. Of course all references in all three languages are resolved correctly in all possible direction.

I think it opens many amazing opportunities of Groovy becoming orchestration language for people who needs both static and dynamic typing plus functional programming. Of course I would like to see it as part of Groovy Core.

I would like to learn what other people think about it. Please let me know.


7 Responses to Groovy+Scala+Java

  1. Wow, that’s impressive! Makes me rather glad that Groovy’s compiler does things so differently. 🙂

    The unfortunate thing is that this sort of problem will only expand exponentially. For every new language added to the JVM, if there is even a modicum of popularity involved, there will be some serious pressure to add joint compilation support. So far there are really only three major contenders in this arena and their joint compilers just *happen* to be compatible. However, your trick with the ordering isn’t going to work with a fourth language unless its joint compiler works exactly the same way as Groovy’s.

    I really think that a more general framework is required here, one which can serve as a point of commonality for the symbol tables for all compilers involved. In this way, adding a new compiler to the joint compilation process would only be a matter of loading up that compiler “plugin”. This framework would make it possible to trivially mix and match languages, all with seamless joint compilation support.

  2. groovyland says:

    Daniel, I agree with you in general – such framework would be great and probably will solve many problems in the future.

    I also think that we should be pragmatic and use what we have. My method (fortunately) solves a lot of problems, which arise right now, and it might make sense to create joint effort between Groovy and Scala communities to implement it in our products.

    Does it make sense?

  3. Perfect sense. I agree that your solution is the only viable one in the short term. My point is that this is only going to become a larger and larger issue as the “polyglot revolution” begins to take hold. The sooner we start thinking about such a common framework, the less headache we will have to endure down the road.

  4. Oh, on a moderately-related point, the Scala team is also working on a Scala2Java compiler, which produces compilable Java sources from Scala. It isn’t mature yet, but if and when it is completed, it might become a helpful component down the road if and when another static language decides to do joint compilation like Scala rather than Groovy.

  5. groovyland says:

    The real problem is that we can’t expect Sun’s collaboration on that… Even if they are the best candidate to drive the effort

  6. Yeah, I had thought of that. I suppose that it depends on how open they are to alternative JVM languages, and by all reports they seem to be very much in favor of such efforts (hiring of the JRuby and Jython guys, etc). Another approach might be to develop/adapt a completely open-source Java compiler. It’s not exactly the most difficult language to compile, and with the JCK available for community usage, it would be possible to bundle such a compiler with the OpenJDK libraries and actually call it “Java”.

  7. josefbetancourt says:

    Now that Groovy++ is on its way, is this needed? If I understood it correctly, Groovy++ will allow static typing like in Scala. But this is for performance reasons only? Will not bring in Scala’s language features.

Leave a Reply to Daniel Spiewak Cancel reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: