Method missing in Groovy - Part 2

In my previous post I showed how to use invokeMethod to provide "method missing" behaviour in Groovy. Well, if you're prepared to live on the cutting edge and install the latest Groovy 1.1 beta 3 code from SVN then you can try out Groovy's new "method missing" feature that will be more familiar to Ruby programmers.

This came about after I had a productive discussion with Charles Nutter of JRuby, and in the spirit of cross pollination here is the example from my previous post using the new "method missing" feature of the upcoming Groovy 1.1 release:



1 def dynamicMethods = [...]
2 Book.metaClass.'static'.methodMissing = { String methodName, args ->
3   StaticMethodInvocation method =
4           dynamicMethods.find { it.isMethodMatch(methodName) }
5   if(method) {
6        Book.metaClass.'static'."$methodName" = { Object[] varArgs ->
7            method.invoke(Book.class, methodName, varArgs)
8        }
9        result = method.invoke(Book.class, methodName, args)                                                                                                   
10   }
11   else {
12       throw new MissingMethodException(methodName, Book.class, args)
13   }
14   result
15 }

So what is the difference between this and invokeMethod? Well invokeMethod will deal with every method call and hence has a certain amount of overhead. The behaviour of invokeMethod is more useful for AOP type use cases where you need to intercept a method call and wrap behaviour around the invocation.

The "method missing" approach will only take effect when a method is not found to invoke using the normal runtime and hence has no additional overhead plus the code is a bit more concise. Thanks for the help Charles! ;-)

Dealing with method missing with Groovy's MetaClass system

One of the new features coming up in Groovy 1.1 to be released later this year is ExpandoMetaClass. Its an elegant API to programatically extend a class' functionality with Groovy's Meta Object Protocol (MOP).

An example of how we take advantage of this is Grails' dynamic finders in GORM. Dynamic finders allow you to do things like Book.findByTitleAndAuthor("It", "Stephen King"). So how are these implemented in Grails?

First we defined an interface that allows the matching of a method signature to a given method pattern. That interface goes something like this:

interface StaticMethodInvocation {
   boolean isMethodMatch(String methodName)
   Object invoke(Class theClass, String methodName, Object[] args)
}

The implementation of this interface just uses regular expressions to match the method signature. Simple enough. So how do we use this from the MetaClass itself? Well, this is where the magic of ExpandoMetaClass comes in as it allows us to override a static "invokeMethod" in Groovy:

1 def dynamicMethods = [...]
2 Book.metaClass.'static'.invokeMethod = { String methodName, args ->
3    def metaMethod = Book.metaClass.getStaticMetaMethod(methodName, args)
4    def result
5    if(metaMethod) {
6         result = metaMethod.invoke(dc.clazz, args)
7    }
8    else {
9         StaticMethodInvocation method =
10                dynamicMethods.find { it.isMethodMatch(methodName) }
11        if(method) {
12            Book.metaClass.'static'."$methodName" = { Object[] varArgs ->
13               method.invoke(Book.class, methodName, varArgs)
14            }
15            result = method.invoke(Book.class, methodName, args)                                                                                                    
16         }
17         else {
18             throw new MissingMethodException(methodName, Book.class, args)
19         }
20    }
21    result
22 }

So what is actually happening here? First we look to see if the method already exists
on the line:

3    def metaMethod = Book.metaClass.getStaticMetaMethod(methodName, args)

If it does we simply invoke the method:

6    result = metaMethod.invoke(dc.clazz, args)

Otherwise we attempt to find a method that matches the method signature using a previously defined list of StaticMethodInvocation instances:

9    StaticMethodInvocation method =
10          dynamicMethods.find { it.isMethodMatch(methodName) }

If the method exists we dynamically register a new method on the MetaClass so that the next time the method is invoked it doesn't have to go through the matching process and will simply dispatch like normal:

12    Book.metaClass.'static'."$methodName" = { Object[] varArgs ->
13         method.invoke(dc.clazz, methodName, varArgs)
14    }

Finally, we invoke the method itself, or if the method isn't matched we throw a MethodMissingException:

15    result = method.invoke(dc.clazz, methodName, args) 

Job done. As simple as that ;-)

I'm doing a talk at the Grails eXchange about the Grails plug-in system and how we dynamically extend the behaviour of classes. See you there!

Groovy 1.1 beta 2 out. Configuration made easy with ConfigSlurper

So we've put out the 1.1 beta 2 release of Groovy, which is a really significant milestone for the project. Guillaume has the lowdown of all the new features in his blog.

One of the things I worked on for this release was a new utility class called ConfigSlurper. It allows you to write configuration files as Groovy scripts in a Java properties file like format. What advantage does this give you?

1) You get to take advantage of native Java types and not do type conversion from properties
2) You can use "global variables" and write more DRY configurations
3) You can take advantage of Groovy's advanced syntax for lists and maps to make config easier

Here is an example of configuring log4j with a ConfigSlurper script:

log4j.appender.stdout = "org.apache.log4j.ConsoleAppender"
log4j.appender."stdout.layout"="org.apache.log4j.PatternLayout"
log4j.rootLogger="error,stdout"
log4j.logger.org.springframework="info,stdout"
log4j.additivity.org.springframework=false

Not that disimilar from standard Java properties files and you can convert to and from Java properties files, merge configurations and serialize them back to disk. To use this this script you can use the ConfigSlurper class to parse it:

def config = new ConfigSlurper().parse(new File('myconfig.groovy').toURL())

assert "info,stdout" == config.log4j.logger.org.springframework
assert false == config.log4j.additivity.org.springframework

We're using this as our primary means to deal with necessary configuration (not possible by convention in Grails. Checkout some more examples of its usage here.

Getting JetGroovy up and running with IntelliJ IDEA

I've blogged about it before, but I can't express how impressed I am by the work JetBrains have done on their Groovy plugin. Code completion, CTRL+click navigation from Groovy to Java and Java to Groovy, some refactoring support, joint compilation of Groovy and Java. JetGroovy really makes mixing Groovy & Java in the same codebase completely seamless.

How do you get setup? Follow these steps:

1) Download and install the IDEA 7.0 EAP from here
2) Download a stable binary of JetGroovy from here
3) Unzip the zip file into the IDEA_HOME/plugins directory
4) Start IDEA
5) Open up the JetGroovy preferences dialog in Settings/Groovy&Grails and point IDEA to your Groovy & Grails installs
6) You're done

Make sure you checkout the feature tour here. If you're not a IntelliJ user, don't forget their is also a lot of excellent work happening around the Eclipse plugin. Enjoy!

5 More Misconceptions About Grails

Update: InfoQ have featured the two article's in a Grails Misconceptions post. Discuss!

Grails committer Marc Palmer posted a nice entry expressing 10 common misconceptions about Grails and what it is about.

This was linked to from another interesting post entitled Blasphemy: The case against Rails, which highlights the strength of Java and the how "Groovy/Grails is proving itself to be a formidable challenger".

An interesting aspect of the above post however, was the reaction of Ruby/Rails users to the outrageous comment that Grails is a more realistic alternative in the enterprise. Some of the comments including even more classic misconceptions and knee-jerk reactions which I will address in this post. My 5 misconceptions are a bit more long-winded than Marc's, but I think it is needed to address each one completely:

1) "Who needs Grails when we have JRuby on Rails?"

This is a classic and is the foundations for one of the biggest misconceptions about what Grails is. JRuby on Rails is an excellent way to run Rails apps on a Java EE container like GlassFish. End of story. Grails has very different goals. It is not a port of Rails to the Groovy language. It is the act of bringing together solid industrial strength components like Spring, Hibernate, Quartz, Compass, Sitemesh etc. and making them DRY by embracing convention-over-configuration.

We're not re-inventing the wheel and because the vast majority of the core of Grails is Java it is more robust and performant. Grails is actually a Spring MVC application at its core and is deployable onto all major containers, not just Glassfish, including the big commercial ones such as WebLogic, WebSphere and Oracle AS.

2) "Why use Groovy 'the half-way house' instead of just going for Ruby?"

This is another one that is often quoted all over the place. Why bother choosing Groovy when Ruby has the same features (some argue more)? Well this one misses the aims and goals of Groovy completely. Groovy IS NOT intended as a replacement for Java. Groovy (and Grails) are designed to be used symbiotically with Java.

Java is a great programming language for many general tasks, don't let the zealots persuade you otherwise. In the same sense Groovy is excellent at what its good at. For example Java is great for writing complex business logic or low-level plumbing code. Groovy is better at a higher level. Groovy and Java are meant to be used together.

This is starting to become more clear with the development of Groovy IDE support. The JetGroovy plug-in from IntelliJ allows you to have circular references between Groovy and Java code and ctrl-click navigate from Groovy classes/methods to Java and vica versa. It is awesome stuff. Groovy developers use Groovy because we love Java, the language, the libraries and the platform.

3) "Why is Grails more suitable than Rails for the enterprise?"

A number of reasons. Two of the biggest ones are Spring & Hibernate. As it stands to day a enormous number of organisations are using Spring & Hibernate. They have existing Spring context, existing Hibernate domain models, and so on.

I was in this same situation before I started working in Grails. Grails is designed to integrate with these frameworks as seamlessly as possible. So for example you can drop a Hibernate domain model written in Java and mapping files into a Grails app and start using dynamic finders and GORM straight away.

In addition Grails controllers use standard Servlet API objects like request, response, session etc. and can sit alongside other servlets. It is after all just a Spring MVC application under the covers. Rails on the other hand is designed almost in a way EJB2 was designed (shock, horror bear with me while I qualify this). In other words you extend framework objects like ActiveController, ActiveRecord etc. which bind you to the framework.

There is also no such thing as a domain model in Rails. Rails models are database tables. This is all well and good, but in enterprises the same domain model is often re-used in multiple applications both desktop and web. This is effectively accomplished in Java by packaging the classes with the mapping files in a JAR.

4) "Groovy/Grails are not a credible competitor to Ruby/Rails"

This one is entertaining. Often the credibility of Grails is questioned because it is newer and has a smaller userbase. However my view on this takes me back to the foundations of Grails. Grails is built on very credible technologies. This point was also addressed nicely in Marc's post.

The other area to consider is the arenas that are being competed in. Grails has two goals primary goals. The first goal is to create a web application framework that is easy, elegant and DRY without sacrificing the platform, technologies and tools on which the Java community is built on. A framework that is suitable for enterprise scenarios (see above). DHH was quite happy to dismiss the importance of the enterprise, we're not.

The second goal is to lower the barrier of entry for Java web development. Make Java web development as easy as Ruby/Rails development. Now these are generally conflicting goals, but on the whole we've done a pretty good job at meeting both requirements up until now. Whether Grails will receive more adoption in one man shops and small companies is up for debate, personally I see it being adopted more in larger organisations.

5) "Why bother with Groovy when Ruby is backed by Sun?"

Sun were kind enough to lend a hand to the JRuby project in their hour of need and should be applauded for doing so. However my standard answer to this one is the best things rarely come directly from Sun (Spring, Hibernate etc. etc.).

Seam 2.0 beta with Groovy Support

Just wanted to say congrats to the Seam guys who have added Groovy support to the latest 2.0 beta. I know they (Gavin, Emmanuel etc.) have been putting a lot of hard work into making Seam easy to use whilst still trying to remain true to the Java EE standards and I think adding dynamic language support, in the shape of Groovy, is a great step in the right direction.

I've said it before and I'll say it again, one of the reasons the Java eco-system is so fantastic is you have a choice. Sometimes too much of a choice, but it is a wonderful space to be in.

RE: Is Scala the new Groovy?

Well it looks like Alex Blewitt has taken the time to excrete some more complete and utter rubbish all over the blog-o-sphere. Clearly, Alex got screwed over big time by the Geronimo guys and is feeling rather, well, left out and hence has chosen to vent his anger on the projects that James Strachan has participated in. Like Groovy.

His article is a complete and utter joke from start to finish. Where shall we begin. First using his clearly limited knowledge of Groovy he claims that it is interpreted. Here is a wake-up call Alex, no it isn't. Groovy is compiled down to byte-code. In fact its not even some weird proxy-like byte code, a Groovy class is a Java class.

He then claims that you can run Groovy on a "cut-down VM". I mean what planet is this guy on? Groovy runs in the standard VM, Alex. Yeh seriously. He even can't get his JRuby facts straight, calling on all his knowledge to claim JRuby doesn't support all of C Ruby's semantics. I think Charles would have a word to say about that.

He then claims that Groovy doesn't have a presence in the enterprise like Python and er.. Ruby? Alex, seriously, have you been in an enterprise lately? They run Java. No joke. Sometimes you get some C# on the client, but seriously Groovy has plenty of presence and there are multiple success stories on this area. In fact Groovy tends to be "just used", without justification obtained, its just another JAR after all.

He claims the Groovy community has a "not-invented here" syndrome. Listen Alex, I'm quite happy to inform you that we based many of the ideas in Grails on Rails and even some of the ideas in GSP on JSP. It seems to me with your Geronimo-envy that it is you that has the problem.

Next-up, he shifts his all knowing, educated knowledge onto the topic of Scala, claiming its a dynamic language to rule all other dynamic languages. Scala is a great language and together Groovy and Scala are phenomenal additions to a Java programmers toolkit, but Alex Scala is not a dynamic language. You seriously need to do your research before writing such complete nonsense.

Scala is a statically typed language with support for functional programming with anonymous functions and closures as well as type inference. It is not, however a dynamic language nor did the designers ever intend it to be. It also has great support for parallel programming, so if you're a Java programmer check it out, but don't check it out because "it is the new Groovy" as Alex claims as you'll be sadly disappointed.

Just to be clear, for the benefit of Alex, Groovy is a dynamic language that supports meta-programming and a Meta-Object Protocol (MOP) like Smalltalk, Ruby and to a certain extent Python. Scala is a statically typed language that supports functional programming more like Haskell.

In fact I should probably do another Myth #X post and just point it to his blog post with a big sign saying "read this and believe none of it". Hopefully, after a few more blog posts that rip into James' previous projects Alex will have exercised his demons and the blog-o-sphere can return to peace.

British Airways: The biggest shambles this side of the Atlantic

Update: My flight has now been delayed until 22:03 since writing this article. It gets better. How they managed to estimate that time to the minute is beyond me. If BA were as good at arriving on time as they are at calculating how long their flights are delayed for we would be sorted.

So I am sitting here in Glasgow Airport (yeh that would be Glasgow, Scotland) waiting for my British Airways flight, which was due to depart at 19:40. However, much to my disgust it has been delayed to 21:20. Now it is not unusual for flights to be delayed, however this is the sixth time I have flown BA in the last 6 months and guess what? Every single flight has been delayed both going out and coming back.

The first time I was like "Well, ok. Every airline has flight delays, even BA!". Then the next time I was "Oh, hmm this is really not good of BA, they're usually so reliable". The third time my demeanor slowly degraded "This is really unacceptable, I can't believe an airline like BA can get it wrong so often". And today? Well I'm fuming. I am beyond angry at this steaming pile of the proverbial that calls itself our national airline.

Due to BA I am instead sitting in Glasgow Airport's below par canteen for dinner instead of having a home cooked meal. Because of BA I am relegated to sneaking into my house in the middle of the night and tip toeing up to bed whilst the rest of my family sleep, instead of being able to be welcomed home at a decent hour. I am honestly disgusted.

It is not like I have not used other airlines. I have flown on Ryanair, EasyJet and Iberia in the last 6 months and none of them have been delayed. How can BA claim it is a "superior" airline to Ryanair and EasyJet when it can't even get the basics right? I mean seriously, on two previous occasions with BA they even managed to lose my flight details even though we had booked the flight and had evidence of doing so!

Just to round the picture off when you actually do get on the flight the food is diabolical, at least on EasyJet and Ryanair you pay for what you get. In all honesty BA are a sham, a complete disaster. They are worse than EasyJet and Ryanair. In fact I would go as far as saying they are perpetuating false advertising with their marketing campaigns that attempt to place them as a "quality" airline.

The funny thing is if you tell someone who actually works for BA this, the first thing they do is blame the ground stuff at BAA. Now I'm sure that the ground staff are equally incompetent, but for heaven's sake the problem has to be corrected somewhere in the chain. Personally, I'm of the view now that there is no compelling reason to chose BA over a budget airline like Ryanair or EasyJet. BA are quite simply awful, and unfortunately for them the leather seats don't make up for it.

Grails vs Rails Myth #1: Grails has a fraction of what Rails has to offer

In this post the author proclaims boldly that Grails has a "fraction of RoRs functionality". So in the spirit of Relevance's myth series (I'm not sure I'll do more than one of these, we'll see) let me sum up my feelings on this.

I would like to have jumped right onto the Rails bandwagon if it hadn't been for the fact that ActiveRecord offers only a fraction of what Hibernate does.

• Where is the proper transaction & conversation support?
• Why is it that it hits the db orders of magnitude harder that Hibernate does and is infinitely slower?
• Where is the criteria support? What about distributed caching?

I would be Ruby maniac right now if Ruby didn't offer only a fraction of what is available in Java. From the reams of web frameworks, to the dozens of persistence engines, to distributed caches, enterprise integration tools and testing frameworks. Java has it all. There is literally a library for everything.

And I would probably have said a long goodbye to Java, if it wasn't for the fantastic innovation that is happening in projects like Spring and Hibernate and the libraries that integrate with them (Quartz, Sitemesh, Compass, Acegi, Webflow et al) which Grails is built on. Want an RMI, burlap, http, soap or DWR service? Just expose one. Need advanced declarative security at the web and business layer level? Plug it right in. Job scheduling? Job done. Search? Sure no problem.

Spring and all the projects that integrate with it, make the Java ecosystem a very happy place indeed. So no, Grails might not have RJS (yet), migrations (yet) or xyz feature from Rails, but it has plenty, thanks to the Java eco-system, to make up for it and then some.

Open Letter to Google: Fix Gmail on Safari

Dear Google,

I'm a regular Gmail user on the Mac. I love Gmail, but I'm torn because I love Safari too. Now that Safari 3 beta is out I feel particularily left out because Gmail is so fundamentally broken on Safari. Maybe there are some deep technical reasons why Gmail doesn't work in Safari 2, but I hope that they can be addressed on Safari 3. So Google, please, please address the following issues so I don't have to keep using Camino for Gmail:

• The back button - this is the most annoying and it is fundamentally broken on Safari. It keeps taking you back to the loading screen. Please fix this it makes Gmail on Safari unusable
• Google Chat - this simply disappears on Safari. Please enable this feature as it too cripples Gmail

With these two problems recitified I would have entered Gmail on Mac nirvana and with Apple and Google's apparent close working relationship these issues should really be addressed otherwise Steve's claim of Safari being the best browser in the world (although this is clearly part of the Jobs reality distortion field) just doesn't hold true and neither does Google's commitment to Apple.

Regards,
Graeme Rocher

Dynamic Groovy: Groovy's Equivalent to Ruby Open Classes

A lot of hype has been made of Ruby's open classes, and for good reason as they're pretty darn cool. Since Groovy classes compile down to byte code (ie a Groovy class is a Java class) it has always been a little more problematic to add dynamic features to classes you don't have control over.

If you're the class implementor for example you could override invokeMethod and getProperty, but if you're not your only option was Groovy categories, which aren't nearly as elegant, or implementing your own custom MetaClass which exposed you to Groovy internals and wasn't very fun.

However, this is all changing because I've just committed major improvements and written the documentation for Groovy's dynamic meta class mechanism, the ExpandoMetaClass. This is the system I discussed with Neal Ford at JavaOne who felt, prior to our discussion, that Ruby had the upper hand because of open classes. After our discussion and a short demo of what ExpandoMetaClass is capable of, Neal changed his mind and upgraded Groovy's rating on his language scale.

So in the next beta release, you'll see a new improved version of ExpandoMetaClass with features such as:

• The ability to add methods onto interfaces
• The ability to override invokeMethod, getProperty and setProperty to provide "missing method" behaviour
• The ability to "borrow" methods from other classes
• The ability to dynamically construct method property names at runtime
  
• Improvements to thread safety whilst performing MetaClass modifications

Here is a little example:

String.metaClass.swapCase = {->
   def sb = new StringBuffer()
   delegate.each {
        sb << (Character.isUpperCase(it as char) ?                    
               Character.toLowerCase(it as char) :                     
               Character.toUpperCase(it as char))       
   }       
   sb.toString() 
}  
assert "UpAndDown" == "uPaNDdOWN".swapCase() 

ExpandoMetaClass has been at the heart of Grails for a while, so is completely production ready. Now its time to bring it to the masses with the next beta release of Groovy targeted for the end of June.

Grails + Wicket: The Wonders of the Grails Plug-in system

Update: A shorter Wicket plug-in installation guide has been added here

A few people have been asking me recently to integrate the Wicket project as a view technology for Grails. What is Wicket? It is a component oriented framework kind of like JSF, but unlike JSF it uses convention-over-configuration and doesn't require you to edit reams of XML. So in this sense its aims are more inline with Grails' aims.

So the question was how do we integrate these two frameworks? Well I thought it couldn't be that difficult and as it turns out, it isn't. So what I did was create a plug-in with "grails create-plugin wicket". The next thing I needed were some jars, so I got Wicket 1.2.6, Wicket Extensions 1.2.6 jar and the Wicket Spring integration jars for 1.2.6 and put them in the plug-ins lib directory.



Job done, now we need to set-up a convention that makes sense for both Grails and Wicket:

1) Since controllers are essentially roughly analogous to the Wicket Application object I decided that the convention would be to have a WebApplication.groovy file in the grails-app/controllers directory.
2) Wickets HTML components are like the views, so they can live in the grails-app/views directory

So to follow the HelloWorld example on the Wicket page we end up with something like this being the structure:



So just for clarify the WebApplication.groovy file looks like this:

import wicket.Page;
import wicket.spring.*;

public class WebApplication extends SpringWebApplication
{
public Class getHomePage()
{
return HelloWorld.class;
}
}

Whilst HelloWorld.groovy looks like this:

import wicket.markup.html.WebPage;
import wicket.markup.html.basic.Label;

public class HelloWorld extends WebPage
{
public HelloWorld()
{
   add(new Label("message", "Hello World!"))
}
}

Finally, the HelloWorld.html file looks like this:

<html>
<body>
<span wicket:id="message">Message goes here</span>
</body>
</html>

Ok so with that done, let's take advantage of the conventions we have in place here. When I created the plug-in with "grails create-plugin" it also created me a WicketGrailsPlugin.groovy file in the root of the plugin project. Since the normal controller mechanism no longer makes sense we modify the plug-in to "evict" the controllers plug-in when installed:

class WicketGrailsPlugin {
def version = 0.1
def dependsOn = [:]
def evicts = ['controllers'] // evict the controllers plugin
 ...
}

With that done we now need to configure the Wicket "applicationBean" in Spring. To do this we're going to use the GrailsApplication object and find a class that is an instance of a Wicket Application. This class just happens to be the one we defined earlier in grails-app/controllers:

import wicket.*
class WicketGrailsPlugin {
...
def doWithSpring = {
def applicationClass = application
                                   .allClasses
                                   .find { Application.class.isAssignableFrom(it) }

if(applicationClass) {
applicationBean(applicationClass) // defines the spring bean
}
}
}

We're of course using the Spring BeanBuilder here to define the bean definition if the Spring context. Ok job done.

Now we need to modify web.xml.. but wait. In Grails even web.xml is created on the fly so other plugins can participate in its generation. So we can do this in the plug-in file again:

import wicket.*
class WicketGrailsPlugin {
...
def doWithWebDescriptor = { xml ->
   def servlets = xml.servlet[0]

   servlets + {
       servlet {
           'servlet-name'('wicket')
           'servlet-class'('wicket.protocol.http.WicketServlet')
           'init-param' {
               'param-name'('applicationFactoryClassName')
               'param-value'('wicket.spring.SpringWebApplicationFactory')
           }
           'load-on-startup'(1)
       }
   }

   def mappings = xml.'servlet-mapping'[0]
   mappings + {
     'servlet-mapping' {
           'servlet-name'('wicket')
           'url-pattern'('/app/*')
      }
   }
}
}

Here we use Groovy's XmlSlurper DSL to modify and the XML simply by using the + operator and some Groovy mark-up. We again use the Wicket Spring integration support to get it all working, so when Wicket loads it will actually look for the bean created by the Grails plug-in. And that's it, to test the plug-in we can type "grails run-app" and navigate to http://localhost:8080/grails-wicket/app and we see:



Not hugely impressive I know, but what it does show is Wicket running as the view tech in Grails which means that Wicket components and applications can use GORM to simplify the ORM layer of Wicket applications and other features of Grails like Services and Jobs. This took me all of 20 minutes to write, in fact I've spent longer writing this article than the plug-in. Not that it is complete of course, things left to do are to add reloading support to the Groovy files that Wicket users. Advice from the Wicket community on how to do that would be appreciated. And of course I haven't tested it against any more complex examples yet.

Now of course it wouldn't be a plug-in if it couldn't be installed into other apps. To do this we package it up with "grails package-plugin" which will create a zip. I've placed in plug-in at http://dist.codehaus.org/grails-plugins/ so in any Grails application you can now do:

grails install-plugin Wicket 0.1

or directly from the URL:

grails install-plugin http://dist.codehaus.org/grails-plugins/grails-Wicket-0.1.zip

And it will install this version of the plug-in.

Note: The plug-in doesn't work with the Grails URL mapping mechanism in 0.5 so you need to delete any grails-app/conf/*UrlMappings.groovy files otherwise you'll get an exception.

Plug-in sources can be found here: http://svn.grails-plugins.codehaus.org/browse/grails-plugins/grails-wicket/trunk

RE: Groovy and Grails: Three Worries

I had the pleasure of meeting and having dinner (at a wondefully steriotypical American diner) with Stuart Halloway along with other NFJS guys like Ted Neward and Brian Goetz at JavaOne. Since then Stuart took the time to write a nice entry with a few pleasantries that he discovered about Groovy & Grails (Thanks Stuart!).

In a follow-up post entitled Groovy & Grails: Three Worries he raises a few concerns which I commented on, but would like to take the time to address here too.

1. Lack of Open Classes in Groovy

His first concern centers around the fact that Ruby has an open class system whilst Groovy does not. The reasons for this are simply Groovy compiles into byte code directly and there is a one-to-one mapping between a Groovy class and a class file. This is unlike JRuby where you need to to use proxying trickys in order to do things like call Ruby from Java.

So essentially Groovy can't modify classes directly because as far as the JVM is concerned once a class is loaded it cannot be changed. Of course this is completely sensible as the Java platform has the concept of threading. Changing class definitions at runtime in a multi-threaded environment would be rather problematic from the JVMs perspective. Since Ruby has no concept of threading at this time of writing the language and runtime has no such concerns.

So given these constraints in Groovy we have a different way of doing things. Stuart presented the following example:

class Person { 
  def firstName; 
}
p = new Person();
class Person {
  def lastName;
}
p.lastName = 'Halloway'

In Groovy (with the upcoming 1.1 release) this would be implemented as:

class Person { 
  def firstName; 
}
p = new Person();
p.metaClass.lastName = 'Halloway'

p.lastName = "Rocher"

This uses Groovy's ExpandoMetaClass mechanism. Since in Groovy we can't change classes, we instead have a MetaClass for each java.lang.Class. The MetaClass defines the behaviour of the actual class. You change the MetaClass you change the class. So Groovy might not have "open" classes, but it has an equivalent mechanism for achieving the same thing.

2. OMG! Grails is not written in 100% Groovy!

Yes that is right Grails is around 80% Java and 20% Groovy. The reasons for this are several. Firstly, Java still makes a great language for writing low-level plumbing code. For dealing with all the complexities that the users of the higher level interface (Grails users) don't have to deal with. Secondly, since Grails is written in Java we get the performance benefits of this. Grails is between 50 and 300% faster than Rails depending on the test. Rails might be implemented in 100% Ruby, but it has very well documented performance troubles because of this.

Do we eat our own dog food? Hell yeah, we have a plug-in system where plugins are all written in Groovy. All of our custom tag libraries are written in Groovy. Groovy Server Pages (GSP), our view technologies, is all Groovy. So we eat plenty of it trust me. Finally, the Groovy community has never been the one to cry out and tell everyone to ditch Java. No, our philosophy is to choose the right tool for the job, and Java is still a great tool in my toolbox just as Groovy is another. The fact that they work so seamlessly together is what makes the pairing so special.

3. The old static typing debate

So is static typing useful anyway? Well yes, it has been useful for a number of things for us such as enabling us to implement more intelligent scaffolding based on the types (java.util.Date, java.lang.String) etc. Also we could implement things like command objects which using static type information.

In addition at the moment the tool support just is not there yet to use either Ruby or Groovy for large complicated applications. Static typing analysis and the features that it brings to modern IDEs like refactoring and code navigation are just in a different league in Java. I hope this will change in time and since Groovy supports both static and dynamic typing I believe the tools vendors will have an easier time creating quality tools for it.

This is also where Grails fits quite nicely into the picture as it allows you to mix Groovy for the simple to medium complex stuff and Java to do the heavy lifting. IMO Groovy gets the balance here just right.

The lone ramblings of a JRuby developer in denial

Jeremy Rayner has a nice summary of all the positive and negative feedback dished out to Groovy at JavaOne the overwhelming majority of which is positive. It is entertaining to see that the most vocal and negative comments come from none other than a JRuby committer Ola Bini.

I can imagine the picture now of Ola sitting in a Groovy session with his fingers in his ears and eyes shut going "nah nah nah I'm not listening!!". Unfortunately Ola, as demonstrated by the vast array of positive feedback and the book sales, really there is only one winner this year: Groovy

Nevermind, there is always next year ;-)

The Grails US Tour: JavaOne Day 3 + Back to London

Well this is where JavaOne ends for me. This morning I met up with Geertjan (famous NetBeans guys from Sun) and his colleague Martin Adamek who were both extremely enthusiastic about Groovy & Grails support in NetBeans IDE. It was great chatting to them and hearing their excitment, it will be great to have Geertjan (and hopefully Martin) over at the Grails eXchange 2007 in October.

After that I went to Rod Cope's (the twice voted JavaOne Rockstar!) talk on "Advanced Groovy", which was awesome. Again a fairly full room (although not packed out like Guillaume and Dierk's Groovy talk) with around 300 people. The demos he did were fantastic, involving XML-RPC, ActiveX automation and all sorts. Very well put together, I imagine he has a chance for a hatrick of Rockstar nominations.

Now its back to the UK, with my flight leaving tonight. I'm looking forward to seeing my family and returning to some sense of normality, but it has been a blast. Thanks go out to the No Fluff guys, the JetBrains guys and of course Sun for letting me do the half day Groovy/Grails talk which was very enjoyable.

Overall the conference has been a great success with so much excitment about Groovy and Grails. Hopefully we've impressed enough people to encourage greater adoption of Groovy as the major dynamic language platform for the JVM.

The Grails US Tour: JavaOne Day 2

So I just finished my BOF on Grails + Spring & Hibernate. It went ok, I'm a little disappointed actually. My talk was at 9:55pm which is like the graveyard shift with fewer people than other sessions and tiredness had really started to set in for me after all my talks at NFJS, JavaU and then all the parties and dinners.

I fear I grossly overestimated the audiences' potential knowledge of Groovy & Grails, a schoolboy error of course. It was a fairly advanced talk showing mixing Java entities and Grails domain classes in the same codebase and using remote Spring services. I fear it may well have been more effective to have done a similar introductory talk as last years JavaOne.

I could kind of gage this from the audiences' blank looks as I was doing the talk which made me rush through some parts to avoid some of the complexity leaving the talk shorter than it should have been. I fear I left the audience thinking that Grails is complicated when in fact what I was trying to demonstrate was Grails is simple when you need it to be and flexible (spring+hibernate integration) when you need it to be.

Oh well, you win some you lose some, I'm trying not to be too down beat as it has still been very worthwhile as the buzz I got from the NFJS and JavaU talks plus the Groovy talk by Dierk and Guillaume was totally different. And we received some awesome news about the book sales. On day one the Groovy book sold out by 4pm and the Grails book was 4th on the best seller list. Check it out Groovy & Grails has proven really popular this year so its been awesome.

So much cause for celebration, even if my talk was not what I hoped it to be...

The Grails US Tour: JavaOne Day 1

Another eventful day at JavaOne is winding to a close. It was another great day from a Groovy perspective with the Groovy session filling up with around 600 people in it with the rest losing out. Guillaume and Dierk did an awesome session about Groovy with some neat demos, which the audience really enjoyed. We then all went to a book signing at the Digital Guru bookshop, which was enjoyable.

The big news of the day was of course JavaFX. I've looked over the samples and can't really see why a new language is needed as it can be done with an almost identical syntax in Groovy's SwingBuilder. The only "feature" that seems to differentiate it is that you can bind multiple references to the same value. The result here is that if you change the value if changes all references to it. This of course can be achieved with Groovy closure's too. Nevertheless, it is too early to tell, I haven't had a chance to look at it in any detail so maybe I'm missing something.

Later in the day we had dinner with the JetBrains and the No Fluff guys and it was great to see so many people getting together and being enthusiastic about Groovy and Grails. Onto Day 2....

The Grails US Tour: JavaOne Day 0 + G2One

Well its the morning of JavaOne Day 1 and now for my Java University report. So basically I did a half day Groovy & Grails talk at the Java University and the response was brilliant. There were a 150 people and doing a half day event really gave me the time to get into the detail of Groovy & Grails and do some good demos. The audience were mostly blown away by the awesome things you could do with Groovy & Grails and it was fantastic to hear the response. After hearing that some of the other talks were a disappointment it was good to hear mine got a tick in the box.

Next up was No Fluff Just Stuff's G2One event which was good too. I wish though I had had more time to do a longer more interactive session as 30 minutes felt to short to get my points across, but it was good fun and I met some interesting people who were interested in Groovy & Grails as over 200 people showed up for the event which is a great turnout. Ted Neward conducted a panel discussion featuring myself, Guillaume, Dierk, Neal Ford, Andy Glover and Jason Rudolph (who I finally got to meet) that was great fun.

The attendees asked some of the typical questions such as IDE support, JRuby vs Groovy and of course "When is Grails going to support Maven!". I believe we were able to answer most of them in an effective way. Most Java people are still a little afraid to leave the comfort of their trusty IDE which is understandable.

After the event I stumbled across James Strachan who I had yet to meet, it was late in the evening and James was a little on the merry side, so we didn't really have a chance to chat much, but made the introductions and hopefully we will during the conference.

I also met Alex Tchakman of JetBrains who is leading the effort to develop a Groovy/Grails plug-in for IntelliJ IDEA. It was fantastic to hear how excited he is about IntelliJ and the future of the Groovy/Grails plug-in for it. I can't wait for October when it will be unveiled to the public.

Finally, I woke up this morning to the news that we have been biled. What did Rod Johnson say? "You haven't made it until you've been biled". Groovy and Grails rock :-)

The Grails US Tour: Arrived to San Francisco + NFJS Denver Report

So I'm sitting here in my hotel room having just arrived to San Francisco after the 2 and bit hour flight from Denver. The No Fluff Just Stuff show in Denver was really fantastic and I was amazed to see so many passionate Java developers coming together on their weekend to talk techie. I met some great people including a few of the regular No Fluffers such as Neal Ford, Ted Neward and Scott Davis. And of course I had the pleasure of meeting the man himself, Jay Zimmerman.

I also managed to take in a couple of sessions and saw Seam demo'ed properly for the first time. My thoughts? Well it certainly papers over the warts of JSF, but it is still a lonnnngggg way away from the claimed "Ruby-on-Rails like" productivity. What summed it up perfectly for me was a moment in David Geary's talk where he created a CRUD app and claimed "it only took 40 lines of config and a 100 lines of Java!". I was tempted to stand up and say well I could have done that in about 10 lines of Grails code with scaffolding and no config, but thought better of it.

Of course Seam will get its users because of the whole "standards" approach that it has, but in terms of developer experience it is miles from Rails or Grails. Moving on, at the conference I did three talks on Grails covering Spring/Hibernate integration, GORM and plug-ins that were all completely packed out and the response was superb.

However, the moment that pleased me the most was near the end where the majority of the 250 attendees gather in the main presentation room and Jay asked them who would be using the various technologies presented. When asked about JRuby about 10 people raised their hands, when asked about Seam around 15 did, when asked about Groovy & Grails the majority of the audience raised their hands, far too many to count anyway. My (and Scott's) work here is done. Next...

The Grails US Tour: NFJS Denver & JavaOne

Today begins my week long tour of the US doing various talks about Groovy & Grails. First up I'm heading to Denver to do 3 talks on Grails at No Fluff Just Stuff's Rocky Mountain Software Symposium, which should be fun. I then get a connecting flight to San Francisco where I'll be doing a half day Groovy/Grails Java University talk at JavaOne next week Monday. Also on Monday there is the Groovy/Grails G2One event I mentioned the other day which is also organised again by the NFJS guys.

Hopefully I'll then have time to take in some sessions before doing a couple of talks, first a Intro to Grails talks at the Oracle booth followed on Wednesday by my BOF. The schedule looks challenging, I imagine jetlag will kick in promptly, I'm going to miss my wife and kids like crazy, but it should be good fun. See you there!