Graeme Rocher's Blog

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.

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:

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.

Apologies to frequent readers of this blog that I've been a bit quite, but we're plowing away trying get get Grails 1.0 out in time for Christmas. In the meantime an incredible amount of activity has gone on around the Grails community.

Firstly, congrats to Martin and Geertjan from Sun for their work on the NetBeans Groovy/Grails integration, it looks very promising and it is nice to see the progress made by the open source IDEs given the great support we have in IntelliJ iDEA.

Next thing I wanted to mention was the incredible amount of code that is being written by the community to make Grails even better. The guys at Catalina Consulting have created no fewer than 3 new plug-ins that provide integration with Amazon S3, the Red5 Flash Server and Streaming Video support to Grails.

However, there is more! To further increase Grails' integrations with Java based Ajax stacks two new plug-ins have been created by our users. The ZK Grails Plugin provides integration with ZK, a rich event-driven, component oriented Ajax stack. Whilst, the Echo2 Grails Plugin does the same for Echo2, another component oriented Ajax stack that lets you create Ajax apps in a similar way to Swing.

What is interesting for me about these two plug-ins is:
Other things of significance include the launch of 4 new public Grails based sites in the past month, including:
Congrats to the guys behind those sites. So overall exciting times for Groovy and Grails and with 1.0 out soon, hopefully 2008 will be another big year.

The JetBrains folks have contributed a great write-up on the wiki summarising the powerful capability offered by JetGroovy, their Groovy/Grails plug-in for IntelliJ IDEA.

I have been meaning to do a write-up on the Grails eXchange 2007, a great conference hosted by my former employers Skills Matter.

Overall the conference was great, it had the feel of some of the No Fluff events I've been to and it was awesome to have so many people passionate about Groovy & Grails in the same place.

Some of the highlights for me were seeing the amazing JetGroovy plug-in in action demo'ed by JetBrains, Meeting the awwwesome (pronounced with a proper ozzy accent of course) Glen Smith (the man behind Groovy blogs) and his presentation entitled "The Whole Nine Yards" and the general networking and social aspect.

Now its back to focusing on getting Grails 1.0 out. My current focus is not on code, but on improving our documentation. Stay tuned.

"The main message I'm going home with is the rather obvious realisation that Groovy is in a completely different category to any other scripting language, because of its relationship with Java. Hence, lots of stuff (such as the Java debugger, as indicated above) can simply be reused when working with Groovy. That insight should also inform the tooling provided for Groovy." - Geertjan at the Grails eXchange

This is a great quote from Geertjan from Sun and highlights what we've been saying about Groovy for years: Java integration is more than being able to invoke a method on a Java class, it is object model integration, tools integration, debugger integration, profiling integration etc. etc. etc.

You can probably tell by the title that I am trying to cram too much into one blog post, but anyway there you go..

First off, we released Grails 1.0 RC1 there first of a few release candidates that will go out before 1.0 final. Check out the release notes for all the good stuff in this release.

Second, JetBrains have released IntelliJ IDEA 7.0. What was simply the best Java IDE on the planet is now also simply the best Groovy/Grails IDE on the planet. Congrats to the JetBrains guys and check it out.

Finally, today was day 1 of the Skills Matter's Grails eXchange conference which went well. It has the feel of some of the No Fluff conferences I've been to and it is great to have so many people excited about Groovy & Grails in one place. Big thanks to Skills Matter for organising it all.

As announced to the Groovy & Grails mailing lists today we communicated the formation of G2One Inc, the source for Groovy/Grails expertise and today is my first "official" day as CTO at G2One Inc.

Almost overnight we now have like 4 fulltime people working on Groovy/Grails and what a difference it makes.

Exciting times. The ball is now rolling !

PS A special thank you to the guys at Skills Matter who I have, up until recently, been working for, for the past year. They're organising a great little Groovy/Grails get together and have been superb in their support for Groovy/Grails over the last year.

SAP, one of the largest providers of enterprise software and services in the world today, have been using Groovy/Grails internally for a while now. I first met the nice chaps from SAP at JavaOne in May where they attended my half-day Groovy/Grails workshop.

However, the big news is the announcement that they have released a new community driven product called Composition on Rails (Side note - not sure DHH and co will be happy with the name, oh well...) that allows you to use their SAP NetWeaver Composition Environment to quickly prototype applications using Groovy/Grails. Exciting stuff!

The guys over at popular networking site LinkedIn are looking for software engineers with experience building web 2.0 apps preferably with Groovy/Grails. Check it out.

Software consultancy Refactr have posted a great interview with Marc Palmer, one of the committers for Grails, about his experiences developing Grails apps.

Just finished my talk on Grails at JAOO. It went very well, the room was packed out with people having to stand at the back. Grails was extremely well received and the audience enthusiastic.

The conference seems interesting, there aren't many low level technical talks. Most talks seem to be design or patterns or enterprise architecture talks. There are also many .NET talks, so its quite a diverse conference. An interesting concept.

JAOO uses a system of rating talks with red, yellow and green papers depending if the talk was rubbish, average or good. I managed 15 yellows, 98 greens and no reds. Not bad :-)

As announced by Guillaume, Groovy 1.1 beta 3 is out and the final release is just round the corner. There is lots of good stuff in there, but I want to talk here primarily about the new meta-programming API improvements that have been introduced in this release.

Groovy has always had the underlying Meta Object Protocol (MOP) that allowed the same behaviour as languages such as Ruby and Small Talk, however the API onto these has, up until now, not been as elegant as it could have been. With Groovy 1.1 beta 3 there is a lot more at your finger tips including...

Runtime evaluation with respondsTo & hasProperty
It is now a lot easier to inspect the runtime thanks to the addition of hasProperty and respondsTo for meta classes so you can do:

class Foo {

    String name = "Wilma"

    def sayHello() { println "hello $name" }

    def sayHello(String message) { println "hello $message" }

}

def f = new Foo()



if(f.metaClass.respondsTo(f,'sayHello') {

    f.sayHello()

}

Since Groovy supports method overloading and typed arguments to support good Java interoperability you can also specify a type:

if(f.metaClass.respondsTo(f,'sayHello', String) {

    f.sayHello("Fred")

}

Groovy also differentiates method and property access so you can do this:

if(f.metaClass.hasProperty(f,'name') {

     println f.name

}

See the docs here for more info on hasProperty and respondsTo

Missing method/property interception with methodMissing & propertyMissing

As of beta 3, Groovy now supports the concept of "method missing". It has always been possible to intercept method dispatch using invokeMethod. However, this has the overhead of intercepting every method call instead of just the "missing" ones. As of Groovy 1.1 beta 3, Groovy now supports "method missing" and "property missing", which are only called when method dispatch fails (ie just before a MissingMethodException would be thrown anyway.)

A trivial example can be seen below, we use this feature in Grails to implement dynamic finders such as findByTitleAndAuthor("Groovy in Action", "Dierk Koenig"):

Foo.metaClass.methodMissing = { String name, args ->

    Foo.metaClass."$name" = { Object[] varArgs -> 

        "$name : ${varArgs.inspect()}" 

    }

    delegate."$name"(args)

}



def f = new Foo()

f.sayHello('Fred')

assert f.notARealMethod("boo") 

            == 'notARealMethod : [["boo"]]'

assert f.notARealMethod("boo", "hoo") 

            == 'notARealMethod : [["boo", "hoo"]]'

Notice how in the example above we can dynamically register a new method on the fly and then call that method. This also has the implicationthat the next dispatch to the same method is faster. See the docs here for more info and there are a whole load of docs on doing dynamic Groovy and meta-programming to be found here.

Gavin King has been featured in a podcast where he has some nice things to say about Grails. Transcript here. Thanks Gavin! For what its worth Seam makes JSF palatable ;-)

In related news Gavin also has a blog post about the downside of ActiveRecord storing model info in the DB. The funny thing is this is nothing new, we realised that having your model in the DB was a crap idea from day one when we created Grails. That is why GORM has not such deficiencies.

This latest little outburst from David HH of Rails fame is hilarious. Even Charles Nutter must be on the floor laughing. David honestly believes that JRuby is a bridge for people to move to the C Ruby runtime because its a superior environment without the "junk"? I had to do a double take when I read that.

So let's see, enterprises are going to give up on a platform that provides monitoring, profiling, JIT, a deployment architecture that isn't a joke, threading, a compiled byte-code format, clustering, distributed caching, transactions that don't suck, maturity and performance all to build Rails apps?

Ignore the enterprise, it is ok. Grails is settling in quite nicely in the enterprise, and everything else will flow from there ;-)

We've just released Grails 0.6 which takes Grails even further away from its Rails-like beginnings. Thanks to integration with the Spring Web Flow project and support for Spring scopes Grails now supports rich conversations a la Seam.

The essence of it is that we have created a Groovy builder for construction Web Flows. This is both a good thing for Grails and for the Web Flow project as the current mechanism for flow definition in Web Flow is via XML which has limited expressiveness and too many angles for my liking.

An example of a Grails Flow can be seen below:

 showCart {

    on("checkout").to "enterPersonalDetails"

    on("continueShopping").to "showCatalogue"

 }                                         

 enterPersonalDetails {

  on("submit") {

   def p = new Person(params)

   flow.person = p 

   def e = yes()

   if(p.hasErrors() || !p.validate())return error()    

  }.to "enterShipping"   

  on("return").to "showCart"

  on(Exception).to "handleError"

 }              

 enterShipping  {

  on("back").to "enterPersonalDetails"

  on("submit") {

   def a = new Address(params)                           

   flow.address = a

   if(a.hasErrors() || !a.validate()) return error()    

  }.to "enterPayment"

 }

Web Flow will completely manage the state transitions and Grails integrates Hibernate into the picture to make sure you get atomic conversations.

You can also encapsulate business logic inside service classes and define services as living in a particular scope:

class BookService {

   static scope = "flow"

   ...

}

Thus allowing conversations with a particular service scoped to individual clients. It is all rather exciting stuff and extends Grails' capabilities allowing much more complex workflows.

This is not the only exciting feature in Grails 0.6. The headliners are:

* Joint Groovy/Java Compilation
* Spring Web Flow Integration
* Support for Spring scopes to allow scoped services
* Improved support for REST with automatic XML/JSON marshalling and RESTful URL mappings
* New Config DSL for configuration not possible by convention
* Refreshed scaffolding interface and branding
* Support for Sitemesh inline decorators
* Controllers can now call tag libraries as methods
* New GSP tags
* Massive improvements to speed of start-up time, unit tests and generation tools

Checkout the full release notes for details and download here

A while ago I set-up my Airport Extreme router with my Virgin Media cable connection and it was painful, but I got it working. Anyway, a friend had similar trouble so I helped him set up his and given that this might be a relatively frequent occurance and Virgin's support for Apple products equates to zero I thought I would post the info here for others to benefit.

Step 1) Plug in the relevant cables

I'm not going to go into detail here, but basically plug the ethernet cable into the "Ethernet" slot of the set-top box then the other end into the router in the slot with the circle of dots around it. Make sure the set-top box is powered on and the router is too.

Step 2) Install Airport Extreme Software Update

Chuck in the Apple provided CD and run the installer, then reboot.

Step 3) Enable Wireless and Connect to the Base Station

Enable your wireless connection and then connect to the Wireless network. It is probably called "Apple Base Station" or some generic default name.

Step 4) Run "Airport Utility"

Run the "Airport Utility" program in "/Applications/Utilities/Airport Utility". Then it should automatically discover your base station. Click on the base station and then click the "Continue" button in the bottom right. When prompted choose "Assist me".

Note: Do not confuse it with "Airport Admin Utility" this is the older software.

Step 5) Network/Base Station Name

Select an appropriate network and base station name. Anything you like really.

Step 6) Country/Radio Mode

Choose your country (ie United Kingdom for Virgin Media) then set the Radio Mode. If you have any already Macs or PCs you may need to be 802.11a compatible.

Step 7) Security

Set-up security, don't choose WEP as it is known to be insecure. Select WPA2 Personal and enter an appropriate password of your choice (make sure to check the "Remember password in Keychain option")

Step 8) How do you connect to the Internet?

Select "I use a DSL or cable model with a static IP address or DHCP" then continue

Step 9) Internet Setup

Now the fun begins. If it weren't that Virgin Media's customer service people were so incompetent this bit might not be such a pain, but in my experience they gave wildly different numbers for the primary and secondary DNS depending on who you spoke to. Anyway, enter the information as per the below:

DNS Server:
Domain Name: ntlworld
DHCP Client ID: (Your Virgin Media PID - phone them if you don't know what this is)

Some Virgin Media reps stated you could leave the DHCP Client ID blank, but in my experience this didn't work when setting up both mine and my friends. Once you're done click "Continue"

Step 10) Enter a base station password

Make sure you enter a "base station" password and then once you're done click the "Update" button.

At this point your Apple router will reboot, but it is likely it will flash an Orange light and give several error messages relating to different things. So go back to "Airport Utility" and click on the router again and the "Continue". Now instead of "Assist Me" select "Manual Setup".

Step 11) Share a public IP address

The router is probably set-up in bridge mode. This is problematic as it means you have to do the whole "NTL provisioning" thing for each machine in the house, a pain. So instead in the "Manual Setup" screen of "Airport Utility" select the "Internet" tab.

Now at the "Connection Sharing" bit under the "Internet Connection" tab change the "Off (Bridge Mode)" setting to "Share a public IP address".

You may also want to click on the "DHCP" tab at the top and change the lease time to a bit longer if you want to have the same IP for longer.



Once you're done click the "Update" button again and wait for the router to reboot.

Step 12) Diagnosing problems

If the router is still flashing orange go back into the "Manual Setup" bit and in the "Summary" screen click on the Orange icon next to the "Base Station Status" field.

If you get the "Double NAT" problem ignore this for the moment as it is only because the router has been assigned the temporary provisioning IP address from Virgin.

If however you have a "Internet Connection" problem, then unplug both the set-top box and the router then restart the set-top box wait for the lights on it to stop flashing then turn on the router. Once they've both rebooted you will probably still have a flashing orange light, but it should be related only to the "Double NAT" problem mentioned earlier

If you go back into "Manual Setup" of your router and look at the "IP Address" field in of the "Summary" page your router should have an IP Address that starts 10.* etc. This is the private network of the Virgin provisioning system.

Step 13) Provisioning

If the router is only saying it has a "Double NAT" problem and it has successfuly obtained an IP address starting 10.* and not 168.* then you are ready to start the provisioning step.

Open up a browser and go to some common site like google. You will get redirected to a "NTL Provisioning" site that has a big "Start" button on it. Go through the steps. You will need your Virgin PID and password handy. If is not getting as far as the NTL Provisioning screen then try to quit the browser and start it up again then try again.

If this STILL doesn't work then phone up Virgin by dialing 150 on your phone and ask them what the IP address of the NTL Provisioning site is (when we did it started with 173.* but this might change) and then enter the IP into your address bar.

Once you have successfully registered the router with the "NTL Provisioning" system restart the router (turn it off at the wall and on again)

General Advice

When phoning Virgin Media don't mention the words "Apple", "Mac" or "Wireless". They will use any excuse to say they don't support it. Just saying you're setting up a generic router, and need help and they're more open. If they ask the make of the router, fabricate something like a "Belkin router". As I said they're just keen to get you off their backs than anything. Good luck! Also in DNS Server(s) it only has a primary DNS server, enter "194.168.8.100" as the secondary DNS (in the second DNS Server field). 62.253.162.237

Couple of requests for Grails developers (yeh that means Java developers ;-) have appeared on the mailing list over the last couple of days:

Software consultancy ALTERthought posted an analysis of their discovery that Grails is more productive (for them) than Rails. Queue outcry from the Rails crowd including the usual "You stupid Java guys, what the hell do you know" kind of commentry. All rather entertaining.

Of course, having done my bit of Rails dev I don't actually believe that Grails or Rails are more productive than each other if you're using purely Groovy (in the case of Grails) or purely Ruby (in the case of Rails). In fact Rails might still have the edge here due to its greater maturity, nevertheless if you're mixing Java into the picture their is really only one winner. This is what the ALTERthought guys have discovered on their Fortune 200 Grails project.

It is of course a growing trend. More and more and more consultancies are discovering that Grails is easier to integrate with existing Java and legacy systems. With Grails you can do things like:
People of course automatically raise the JRuby on Rails argument, but as of this writing you can't do 1) or 4) of the above list whilst 2) requires some trickery.

The other revelation that Java people are discovering is that they no longer need to abandon their existing Java knowledge to get RAD development. The Java platform now has its answer to Rails, why go else where?

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! ;-)

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!

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.

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!

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.).

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.

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.

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.

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.
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.

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:
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