Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

This example looks at the issues surrounding a mixed Java/Groovy application. This issue only arises when there is mutual dependencies between your mixed language source files. So, if part of your system is pure Java for instance, you won't have this problem. You would just compile that part of your system first and reference the resulting class/jar file(s) from the part of your system that was written in Groovy.

The legacy version of our application

Suppose you have an initial application written in Java. It deals with packages sent through the post. It has the following Postpack class (you would typically need some additional fields but we have simplified our domain to keep the example simple):

Now suppose you also have a sort helper class ZipSorter as follows:

Finally, you have a main application as follows:

A futile attempt at a quick hack

We have been asked to make a version 2 of our application which supports not only Postpack objects but also Box objects. We must also support the ability to sort by weight as well as Zip. We have been given incredibly short time scales to develop the application, so we decide to write all of the new functionality using Groovy.

We start be creating a Groovy Box class and make it behave in the way ZipSorter is expecting, e.g. we make it implement Comparable even though this wouldn't be needed if everything was going to be in Groovy. We then modify ZipSorter to know about Box. We then create WeightSorter and write it to know about both Postpack and Box.

To simplify development (we think) we create separate groovy and java source directories. We develop our files incrementally in our IDE and everything works fine. We think we are finished, so we do a rebuild all for our project. All of a sudden the project won't compile. We dive out to ant and use the javac and groovyc tasks to put compile our separated source directories. Still no luck. What happened?

We inadvertently introduced a cyclic dependency into our codebase and we only got away with it originally because the incremental development style we were using hid away the problem. The issue is that IDEs and current build systems like Ant use different compilers for Java and Groovy. So while Java and Groovy are the same at the bytecode level, their respective compilers no nothing about the source code of the other language. (Recent discussions have begun about how to eventually remove this separation).

Our hack failed because if we run javac first, ZipSorter won't have the Box class available because it is written in Groovy. If we run groovyc first, WeightSorter doesn't have the Postpack class because it is written in Java. Similarly, if using our IDE, we will face the same deadly embrace problem.

A proper version 2 of our application

The way we get around this problem is to define some common interfaces as follows:

Now we write our Java and Groovy parts of the system being careful to refer only to the interfaces, e.g. the Java files would become:

And the Groovy ones look like:

Finally, our main method looks like:

We need to compile the interfaces first, then we can compile the Groovy or Java files (excluding SortMain) in either order. Finally we compile SortMain as it is the class that knows about the concrete implementations. If we were using dependency injection or our own factory methods we could have reduced or eliminated the need to treat SortMain as a special case, e.g. using Spring we could have the concrete classes listed in an external beans.xml file and SortMain whether it was written in Java or Groovy could have been compiled along with all the other files written in its language.

Now when we run the program we get the following output:

For more details, see chapter 11 of GINA.

  • No labels