SAP announces Composition on Grails 1.0

Congrats to the SAP guys who have announced Composition on Grails 1.0, their toolkit for allowing quick development of composite applications on SAP NetWeaver 7.1 which is based on the current Grails 1.0 stream.

The following quote summarises their motivations for choosing Groovy and Grails:


"First, we needed a scripting language that runs in the JVM, so that ruled out some languages right there. Anything that runs outside the JVM will require some duplication of processes, and interprocess communication is more complicated. Second, we felt that Hibernate and Spring were well proven and we wanted to take advantage of them. Finally, the Groovy syntax and lifecycle management is very Java-like. This matters because the availability of skilled programmers is crucial in the enterprise space, and there are loads of Java developers out there."

It is a great to see a company as large of SAP who "gets it". Good job.

Grails at the Spring Experience

Yesterday I did two talks at the Spring Experience about Groovy and Grails which went well. One thing I found interesting is the misconceptions that people have about Grails. The audience here was of a completely different kind to what I normally face and were under the impression that:

a) Grails had nothing to do with Spring. The reality is quite different, Grails is built on Spring, can leverage existing Spring beans and take advantage of all the Spring APIs

b) Grails requires you to leave Java and use Groovy. This was the most shocking one, most people thought to use Grails you have to only use Groovy. The reality is that if we wanted that we would have gone off and used Ruby on Rails. 

The goal of Grails is to create a web platform where you can use Groovy for what its great at and use Java when it makes sense. Grails can completely leverage any existing Java codebase and existing Spring ApplicationContext definitions.

Another interesting event at the Spring Experience was the Web Development BOF on Friday night. The overwhelming cry from Spring users attending the BOF was for Spring to use more conventions on the web layer. Keith Donald asked me to give the audience an overview of the conventions Grails uses.

By the end of it the general audience response was: well why don't we just use Grails? Overall a good result :-)  

RE: Groovy in Ruby: Implement Interface with a Map

Oops, he did it again! Having started off with the disclaimer that he is working with the Groovy community, Charles Nutter has a blog post that demonstrates how to do Groovy's coercion to a Map in JRuby.

Unfortunately, the irony in his post is that all he has done is demonstrate one of JRuby's shortcomings in terms of Java integration: it lacks built in coercion support. All of this is done whilst demonstrating only a small subset of what Groovy's as keyword is capable of.

The Ruby code demonstrated is as follows:

1. module InvokableHash
2.   def as(java_ifc)
3.     java_ifc.impl {|name, *args| self[name].call(*args)}
4.   end
5. end

Which then can be used as a method like:

1. impl = {
2.   :i => 10,
3.   :hasNext => proc { impl[:i] > 0 },
4.   :next => proc { impl[:i] -= 1 }
5. }
6. iter = impl.as java.util.Iterator
7. while (iter.hasNext)
8.   puts iter.next
9. end

If you were to implement this in Groovy you could do:

1. Map.metaClass.as = { delegate.asType(it) }

However, in a further act of irony this code actually uses Groovy's built in coercion support and hence is in fact rather useless. All in one line of code!

What is even more amusing is his post conveniently skips over the fact that the as keyword is a general purpose coercion mechanism for all types of coercion operations, not just maps. For example this is also possible:

1. { println 'foo' } as Runnable

And it can be extended by implementing the asType method.

The most entertaining quote however is this one:

"Now if you ask the Groovy team, they'll make some claim like "it's all Java objects" or "Groovy integrates seamlessly with Java" but neither of those are entirely true."

Charles is trying hard to claim that JRuby's Java integration is no different to Groovy's. To those who want to try a little experiment have a go at this:

1) Write a plain JRuby/Groovy class
2) Write a Java class that creates a new instance of the JRuby/Groovy class and invokes a method on it
3) Set a break point on the Java class and step debug from the Java into the JRuby/Groovy class
4) Compile the sources and put them in a JAR
5) Put the JAR on the classpath of another app and write another Java class that references the JRuby/Groovy class

With Groovy and its joint compiler or IntelliJ IDEA's JetGroovy this is no problem, with JRuby you won't get passed step 2 without have to resort to introducing interfaces, creating dynamic proxies etc etc.

What the Groovy team says is this: Groovy has the same security model, the same debugger, the same profilers, the same object model, the same APIs, and close to the same syntax. For the Java developer its a no brainer.