The Spring Framework is a leading full-stack Java/J2EE application framework. It is aimed primarily at Java projects and delivers significant benefits such as reducing development effort and costs while providing facilities to improve test coverage and quality. It also has mechanisms for allowing beans to be backed by dynamic language code including Groovy and other languages.
Let's have a look at how to use Spring's support for writing dynamic language backed beans to extend an existing Java application. The existing Java application prints out information about countries in sorted order. We want to be able to add new countries and new sorting algorithms but using different languages for each one. Our goal is to not have to change the original Java code but add the new features just through the application wiring.
Suppose we have the following interface:
And the following implementation class:
Spring supports the Dependency Injection style of coding. This style encourages classes which depend on classes like
USA not to hard-code that dependency, e.g. no fragments of code like '
new USA(...)' and no '
import ...USA;'. Such a style allows us to change the concrete implementations we depend on for testing purposes or at a future point in time as our program evolves. In our example above, we might declaratively state our dependencies in a
beans.xml file as follows:
In this example, the
<constructor-arg/> element allows us to use constructor-based injection.
Having done this, we can get access to our beans through a variety of mechanisms. Normally, access to the beans is mostly transparent. In our case though, we are going to make access explicit so you can see what is going on. Our main method might look like this:
Running this results in:
We can extend this example and introduce Groovy in a number of ways. Firstly, we can create the following Groovy class:
And this one too:
So long as the corresponding
.class file is available on the classpath (e.g. by your IDE or by manually running
groovyc), we can simply reference this class in our
beans.xml file. E.g. for the first class we can use:
Alternatively, if the source file is on the classpath, we can use special Spring notation to reference it, e.g. for the second class we can use:
In these examples, the
<lang:property/> elements allows us to use setter-based injection.
If we prefer to code in another language (with a few restrictions - see below), Spring supports other languages too, e.g.:
But wait there's more ...
Suppose now that we wish to sort our countries according to population size. We don't want to use Java's built-in sort mechanisms as some of them rely on our objects implementing the
Comparable interface and we don't want that noise in our Ruby script. Instead we will use Groovy. We could simply write a Sort class in Groovy and reference as we have done above. This time however we are going to use an additional Spring feature and have the scripting code within our
beans.xml file. First we define the following Java interface:
We can then include the Groovy sort code directly into the
beans.xml file as follows:
We now combine all of the approaches above in a final example.
Here is the complete
Our Java code to use this example looks like:
And the resulting output (with a little bit of hand formatting) looks like:
<lang:language/>element so that if your bean source code changes, the bean will be reloaded (see GINA or the Spring doco for more details)
@Propertykeywords and use the latest
groovy-all-xxx.jarinstead of the jars they recommend
<lang:language/>element currently only supports setter-based injection
Currently using the Groovy language through Spring is extensively supported. Using other languages like JRuby takes a little more care. Try restricting your JRuby methods to ones which take and return simple data types, e.g. long and String. You may also find that certain operations don't work as you'd expect when working between Ruby and other languages, e.g. if you defined a
compareTo method in our
Fiji.rb file, it would return
long by default rather than the
int which Java is expecting. In addition, the
compareTo method takes an
other object as a parameter. Currently the wrapping of this other object from Java or Groovy into a Ruby object hides the original Java methods.