Raible Designs

[TSE] Using Dynamic Languages with Spring with Rod Johnson and Guillaume LaForge

Spring 2.0 has dynamic language support. To make it work, you do need a Java interface as a contract between callers and dynamic beans. There's no special requirements on the interface. It's a "POJI" and doesn't have to extend or implement anything. For example:

There's 3 ways of configuring Groovy beans:

1. GroovyScriptFactory <bean> element defining source location and properties
2. <lang:groovy> element from a <lang> namespace
3. POBD (Plain old <bean> definition) - this is unique for Groovy since it can be compiled into Java bytecode

Any of these three options can take injected properties.

To configure a dynamic language component using the GroovyScriptFactory, you need to do the following:

• You need a ScriptFactoryPostProcessor to ensure that dynamic bean definitions are processed at startup
• Create bean definitions using generic GroovyScriptFactory or other language-specific factory

<bean class="org.sfw.scripting.support.ScriptFactoryPostProcessor"/> 

<bean id="messenger" class="org.sfw.scripting.groovy.GroovyScriptFactory"> 
    <constructor-argvalue="classpath:org/sfw/scripting/groovy/Messenger.groovy"/> 
    <property name="message" value="Hello World"/> 
</bean>

The 2nd way to configure Spring to use a bean from a dynamic language is to use the <lang> namespace. A namespace handler is appropriate when you need to create multiple beans to configure a single feature. Another indication that a namespace is appropriate is when your bean definitions follow a certain pattern (i.e. GroovyScriptFactory always requires a constructor argument). Using the <lang> namespace allows the ScriptFactoryPostProcessor to be registered automatically.

<lang:groovy id="refreshableMessenger" 
    script-source="classpath:org/fw/scripting/groovy/Messenger.groovy"> 
    <lang:property name="message" value="Hello World!"/> 
</lang:groovy>

Using the namespace, it's also possible to tell Spring to refresh the bean definition periodically. With this, callers can hold a reference to the bean, which is thread-safe. It's possible to do this because Spring uses its AOP and proxy system to dynamically replace the "target" object. Refreshing is made possibly by using the "refresh-check-delay" attribute.

<lang:groovy id="refreshableMessenger" 
    refresh-check-delay="5"
    script-source="classpath:org/sfw/scripting/groovy/Messenger.groovy"> 
    <lang:propertyname="message" value="Hello World!"/> 
</lang:groovy>

Another feature with the <lang> namespace is using "inline" scripts. Rod says this can be useful for writing stubs, but he generally doesn't recommend using it. You don't want to program in XML, do you?

The last option, which is only possible with Groovy, is to use POBD to define Groovy components. This is only possible with Groovy, because it produces Java classes.

Why would you want to use Groovy?

• May be more concise and simpler than Java to implement a component. Groovy has closures!
• When the interface doesn?t change but the implementation might, for example with MVC Controllers. This can allow you to rapidly develop web applications.
• To use DSL and other capabilities that offer something Java does not.

The capabilities of developing a DSL in Java is pretty limited. Java 5 and annotations allow you to develop a DSL-ish system, but nothing like what a dynamic language can do.

It's not Rod's job to sell us Groovy, so he's now turning it over to Guillaume. Guillaume is the Groovy Project Manager at Codehause and the JSR-241 Spec Lead. I think it's interesting that James Strachan invented Groovy and doesn't seem to be involved with Grails. Instead, he's helping to create Able. I digress...

To get started playing and working with Groovy is pretty simple. Download, install, add GROOVY_HOME to your environment variables and GROOVY_HOME/bin to your path. I'm downloading it now. The 1.0-RC1 release is around 13 MB.

Groovy is a dynamic and agile scripting language for the JVM. It's an OSS project hosted by Codehaus. It was inspired by Ruby, Python and Smalltalk. It generates bytecode for the JVM so it natively integrates with Java libraries. Groovy differentiates itself with its GDK and MOP. The GDK (Groovy Development Kit) has additional libraries to simplify complex APIs and MOP (Meta Object Protocol) has advanced meta-programming features.

Groovy Syntax and Language Constructs:

• Expressive Java-like syntax (flat learning curve)
• Same OO model as Java
• Properties support
• Supports ?duck typing?, and strong typing
• Native syntax constructs for Lists, Maps, regex
• Permits operator overloading
• GStrings: interpolated strings
• Closures: reusable and assignable code blocks

Sample class and script:

At this point, I pretty much tuned out. The slides I have in front of me match most of what Guillaume was saying. In other words, I was able to read the slides and know what I was going to learn for the next 20 minutes. I generally blog these sessions because I've found it's a good way of capturing the information w/o having to pack around the printed slides. However, now that I have all the presentations in PDF form, I'm a little less motivated. I wonder if there's any rules against me simply uploading the PDFs to this site?

Comment from Rod: "This is the 2nd presentation I've co-presented today and the 2nd enhancement I've recognized we should add." Apparently, he received a number of suggestions from Mike Keith in their JPA talk earlier today. I'm not sure what Groovy-support enhancement was suggested.

One nifty thing I did see in Guillaume's demo was a Groovy Plugin for IDEA. Not only does it provide syntax highlighting, but it seems to allow compiling and running Groovy classes as well.

My take away from this presentation? Spring 2.0 allows you to easily use a dynamic language in your application. This can allow you to externalize business rules, programmatic configuration and possibly even write your UI layer with it. With a backend that can CRUD any object (we have this in AppFuse 2.0), a front-end in a dynamic language could be one heck of a combination. Of course, I could just use Grails. I like the ideas behind Grails, but I expect it'd be hard to sell to clients - many of mine haven't even heard of Tapestry!