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
To simplify development (we think) we create separate
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
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
ZipSorter won't have the
Box class available because it is written in Groovy. If we run
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.