Groovy and Java in Mixed Mode

It sucks! It just sucks!

javac is generating byte code. groovyc is generating byte code. bothe are generating byte code for the jvm. From the byte code perspective their is no different between java and groovy. And in the IDE, IntelliJ IDEA, you can easily mix Java classes with groovy classes. No Problem. No errors and no warnings. But as soon you try to compile and to execute everything you get trouble. I did some research and found this article here:

http://groovy.codehaus.org/Mixed+Java+and+Groovy+Applications

It basically says that if you are mixing java and groovy and you have dependencies between them, than it does not work. Because your code at first get compiled with javac and than with groovyc. You have to use interfaces to resolve the dependencies.

Common! Are you serious? Of course their are dependencies if you are mixing java with groovy! And I don’t want write for every single PoJo a fu**ing Interface. That is the Enterprise Overhead approach I try to avoid with a scripting language.

And why it is not possible to compile groovy with javac? I mean their is JSR for groovy. It is standard. It is from the same vendor. And in the end it is anyway just byte code for the JVM. It would absolute make sense! And in that way the groovy + java mix mode problem could be resolved easily.

5 thoughts on “Groovy and Java in Mixed Mode

  1. It is a small quirk. There would be rare situations where you need a cyclical dependency between Java and Groovy. And if you do that, interface would be a small price to pay. No free lunch (except on Friday, right?).

  2. It is very easy to run in dependencies. Imagine you have 3 classes.

    1. User
    2. Building
    3. Location

    User and Location are Java Classes and Building is a groovy class. User contains a list of Buildings and every Building has a Location. If you compile at first with Javac. Java will tell you that it doesn’t know Building. If you at first compile with GroovyC, Groovy will tell you that it doesn’t know Location.

    That is typical for SUN. They are constructing their own Problems. The same with the JSF and Portlet Specification. After the specification for JSF and Portlets have been final they realized that JSF and Portlets are not working together, because the Lifecycle is completely different. Ole ole. That is the reason why they started the http://jsfportletbridge.java.net/ project.

    That happens always because the projects are uncoordinated and the teams are not talking to each other.

  3. One more thing.

    That is the reason why so many people are moving to Ruby and Ruby on Rails. It is easy and pragmatic. And it is working.
    Java and Groovy is just to heavy and not working like expected. Full with heavy standards and most of them just doesn’t make sense.

  4. Just to aid those looking to switch away from Java…

    Not everyone is moving to Ruby. There are plenty of Java shops moving to Python as well. We’ve been converting from Java to Python as it makes sense to do so, and we’ll soon hit the 50/50 mark. We mostly loosely couple the two with sockets and REST/JSON protocols, but we’re doing a little bit of embedding of Python in Java as well with Jython.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s