“Joe”:http://bostonsteamer.livejournal.com/ points me at this “JVM languages shoot-out”:http://opal.cabochon.com/~stevey/sokoban/ comparing the author’s experience with different dynamic languages that run on the JVM.

As of Beta 10, the author had some “fairly painful experiences”:http://opal.cabochon.com/~stevey/sokoban/docs/article-groovy.html with Groovy unimplemented features, bugs, and inadequate documentation.

As of JSR-03, I still find issues with respect to unimpemented features or bugs and the documentation. The release version is not expected until February 2006.

All told, JRuby is looking better by the moment.

Update: Laurel has a JRuby version of the controller up and running; that was easy!

One of the big selling points of Groovy is that a Groovy class is supposed to be able to do anything a Java class can. It was for this reason that we chose Groovy for “Spring on Rails”:http://thebogles.com/blog/2005/09/spring-on-rails/.

Unfortunately, it appear that this is not quite the case. For instance, Groovy classes in scripts cannot be used to extend abstract base classes– the example below will result in an AbstractMethodError from Java if you attempt to run it as a script.

If on the other hand, you compile the script using groovyc, it works as expected, but making that work correctly in our system is going to involve some unwanted hoops and change the way scripts are written.

I’m hoping this is simply a bug and not expected behavior; I’ve filed a bug in the Groovy JIRA database to describe it.

If this can’t be fixed, it makes me wonder whether we might be better off using JRuby as a scripting language. JRuby can’t extend abstract Java base classes either, but Ruby is a more mature and widely adopted scripting language.

---

---- Base.java ----------
abstract public class Base
{
abstract int foo();
}


---- Subclass.groovy----------
class Subclass1 extends Base
{
int foo() { return 1; }
}

Base b = new Subclass1();
System.out.println(b.foo());