Grails at JavaOne & CommunityOne 08

This year, along with Guillaume, I will be presenting 2 talks at JavaOne 08 on Groovy and Grails:

• TS-5764 - Grails in Depth
• TS-5793 - Groovy and Grails: Changing the
  Landscape of Java™ Platform, Enterprise Edition (Java EE Platform)
  Patterns

As well as a single talk at Monday's CommunityOne 08 event:

• S297193 - Grails: Productive Web Development with Groovy, Spring, and Hibernate

See you there!

Using Groovy & BeanBuilder for Spring + Hibernate Integration Testing

Checkout my new Groovy Zone article Using Groovy & BeanBuilder for Spring + Hibernate Integration Testing

Groovy is Java AND Groovy is not Java

There is a new dynamic language shootout featured on InfoQ where Groovy comes out on top as the JVM language of choice for a variety of reasons and one of the reasons cited was that it is a near superset of Java. Queue the comments from the Ola Bini brigade that:

"If you're going to use Groovy the same way you use Java, there is absolutely no gain. Just a performance hit."

However, this sadly is missing the point. Sure, if you write Groovy like Java you get no real benefit, but it provides that migration and, crucially, learning path onto a Groovier way.

Learning a programming language is for the most part trivial and can be achieved in a few days. Learning the libraries is what takes the time. Groovy shares the same Java APIs as standard Java, you know things that you know and love like java.io.File, java.lang.String etc.?

The real difference comes in what it adds to these standard libraries through the GDK. For example great stuff like this:

myFile.eachLine { println it }

def contents = new URL("http://google.com").text

def list = ['a','c','b']
list = list.collect { it.toUpperCase() }.sort()

def text = "Hello World"
text = text - "World"
println text // prints "Hello "
println text[0..-3] // prints "Hell"

Once you learn the "new way" combined with meta-programming capabilities that Groovy has on offer you'll never look back.

Scott Davis came up with a great quote to describe this at the recent 2GX: Groovy/Grails Experience:

"Groovy is Java AND Groovy is not Java at the same time"

In other words, you get the best of both worlds.

The Grails Podcast Returns

Sven is back with his Grails podcast, now a fortnightly event, and even better Glen Smith, the brilliant ozzie behind Gravl and Groovyblogs (2 great Grails sample applications), has joined him!

Check it out.

Using Grails with Atlassian Crowd

The Atlassian guys (creators of JIRA, Confluence etc.) are using Grails for some of their projects and have written a nice article on how to setup Grails, with the Acegi plugin, and Atlassian's single sign-on (SSO) solution Crowd. Nice work.

2GX: Groovy/Grails featured on eWeek

The nice chaps at eWeek turned up at the 2GX:Groovy/Grails Experience and interviewed me and Scott from aboutGroovy on the subject of Groovy and Grails and its relationship to Java. Check it out

2GX: Standalone Spring BeanBuilder from Grails

At 2GX - The Groovy/Grails Experience, I did a presentation on empowering Spring with Groovy DSLs which demonstrated Grails' Spring BeanBuilder in action.

The demo showed how Spring and Hibernate can be dynamically configured at runtime using BeanBuilder and then interacted with via the Groovy shell. I promised a few I would make it available so here it is.

You'll need Groovy 1.5 and Gant setup before you start then just type:

gant start

Enjoy.

2GX: Keynote - The Amazing Growth of Grails

So, I'm back from the 2GX - The Groovy/Grails Experience which was yet another event, brilliantly put together by Jay Zimmerman and the No Fluff crew. The good news is, if you missed out there is another one in the fall/autumn months in San Jose, CA.

The attendance was excellent for such a focused conference with close to 200 people in total all buzzing about Groovy & Grails. I delivered my "State of Grails" keynote on the Thursday evening which went into some analysis of where we are since the release of Grails 1.0 from a growth perspective, but also from a technology perspective.

I wasn't planning to, but a few people at the conference asked me to post my slides to help persuade managers etc. of the viability of Grails, not just from a technical perspective, but from a growth and community perspective. So if you're in the same position, check out my slides, the following is a summary of the contents.

When we released Grails 1.0, Codehaus' bandwith usage went up by a staggering 40gb. The downloads have been in the 10s of thousands since the release and luckily Contegix, the kind folks who host Codehaus, have freed up some extra bandwith for the servers.

The mailing list traffic on the Grails user mailing list has gone through the roof, averaging close to 140 messages a day in January and looking the same for Feb:


The traffic is contributing to make Grails one of the most vibrant communities around anyone one Java web framework according to Nabble:


Further evidence of the growing community is the Grails plug-in eco-system where Grails now has no less than 47 user contributed plug-ins in the plug-in repository representing nearly 2 million lines of user contributed code:


Blog traffic is also on the up, a year ago the blog traffic for Grails was merely a blip on the horizon (all probably posted by me ;-). Now according to technorati people are talking about Grails, a lot:


Clearly, we still have a long way to go to make Grails as hugely popular as things like Spring and Hibernate, but we're heading in the right direction which is great news.

See you at the Groovy/Grails Experience

Last time there was a major Groovy/Grails conference, we promised to get Grails 1.0 out in time for the conference, somehow we slipped a few months ;-)


This time there is no such slippage and the 2G - Groovy/Grails Experience is coming to Reston, Virginia on the 21-23 of Feb! Organised by the No Fluff crowd, it features an amazing amount of great Groovy & Grails talks from some great speakers (other than me of course ;-).

I'll be doing 3 talks on various aspects of Grails and can't wait, its going to be a great event. See you there!

Grails 1.0 is out the door!

We've put the finishing touches on Grails 1.0 and its out. Time to celebrate with some sleep.. enjoy!

RE: Groovy and JRuby: Enterprise-Ready?

There is a report that is being pushed around comments on blog posts with the aim of spreading FUD. The report can be found here:

http://www.huxili.com/index.php?cat=reports&id=ID000188

It is entitled "Groovy and JRuby: Enterprise Ready?" and its conclusion is that Groovy is not due to "memory leaks". The report is complete nonsense of course, and it put together by someone who doesn't understand the different language idioms.

The report provides no code examples, further bringing to question its validity, however it states that Groovy runs out of memory when running these steps:

1. Call shell.evaluate("x = 100")

2. Call System.gc()

3. Thread.sleep(1000)

4. Record used memory

5. Repeating (1-4)

I'm going to have a go at guessing the Groovy code they used. I can bet it goes something like this:

shell = new GroovyShell()
while(true) {
shell.evaluate("x = 100")
sleep(2000)
System.gc()
}

So what is the problem with this code? And why would it result in a memory leak? The answer is that each GroovyShell instance has an internal class loader. Groovy is a compiled language. Even little scripts like this are compiled into classes so over time the class loader just gets bigger and bigger. The solution? Here we go:

while(true) {
new GroovyShell().evaluate("x = 100")
sleep(2000)
}

So what this does is allow the GroovyShell (and its class loader) to be garbage collected by the JVM. When the class loader is garbage collected so are the classes loaded within it. JRuby of course doesn't have this problem as its interpreted.

Judging whether a language is "enterprise-ready" without knowing the language idioms and basing it on a 4 line script is to be honest quite ridiculous, so remember beware of silly "official" looking reports without verifying the facts for yourself.

The Great Language Backlash

Something interesting has been happening in the blogosphere over the last few days. It seemed to all kick-off with Rick Hightowers post on Why Syntax Matters. It seems a mini-backlash is brewing against the Ruby hype.

Rick feels (and this is his opinion) that Sun should ditch JRuby and support Groovy because the syntax and migration path is so much easier for Java developers. He and several commenters on his blog, feel that Ruby is too different to Java. The post was features on JavaLobby and InfoQ.

This is of course the main reason I was sold about Groovy as it eliminates the context switching between languages as they are so similar, but a blog post that got me thinking the most was Cedric's entitled I'm not Tired of Java Yet. And you know what? I agree with him.

Unlike Ola Bini (JRuby committer) who is repeatedly questioning Java, I love Java and still believe it is a great language for many common tasks. Its just not great for everything. In the past Java was seen as "the one language to rule them all". Now as alternative languages like Groovy start to mature, its about picking the right language to solve the problem at hand and that tool is often Java.

Things like processing strings, doing really dynamic stuff and heavy manipulating of collections can get painful in Java. However, its death is highly, highly exaggerated. One of the reasons I believe so strongly in Groovy and Grails is that it is not about ditching Java or the Java platform, it's about embracing it.

Groovy supports true polygot programming when combined with Java thanks to the seamless way they integrate with one another. I, and most Groovy programmers, still love programming in Java and have no plans to ditch it anytime soon. Use each language when it makes sense. It is about using the best tool for the job.

Grails 1.0 RC4 out, not long to go...

Grails 1.0-RC4 is out. Download here. In three weeks 1.0 final will be with us, fun times :-)

Why Grails doesn't use Maven

Update: As of Grails 1.1, Grails now provides Maven support. My personal feelings towards Maven haven't changed much, it is in my view basically the EJB2 of build tools. However, if you want to use Maven with Grails that is now a possiblity.

In his post entitled "Grails - The Good, The Bad and the Ugly", Jonas has some nice praise for Grails, his main beef is that it is not built on Maven.

So I wanted to clarify why exactly we chose not use Maven (by default) and the explanation is there for all to see in Jonas' first example of creating a Grails application vs creating a Maven project:

Instead of

grails create-app name

could be just

mvn archetype:create -U \
-DarchetypeGroupId=net.liftweb \
-DarchetypeArtifactId=lift-archetype-blank \
-DarchetypeVersion=0.4 \
-DremoteRepositories=http://scala-tools.org/repo-releases \
-DgroupId=your.proj.gid -DartifactId=your-proj-id

My goodness, what a mouthful the Maven example is. There is a common acronym in the open source world called RTFM (read the *ing manual), when a user asks a question on a mailing list and the "experts" respond by pointing them to the place in the manual.

For me Grails is all about dramatically simplifying, and reducing the cases where you have to RTFM. Grails wraps popular Java libraries like Spring, Hibernate, Sitemesh and Quartz and does a damn good job of hiding that complexity.

I'm not saying you never have to RTFM manual, but once you have learnt Grails the cases where you need to are few and far between and for simple things like creating an application, once you know how, you never need to go back. In other words Grails is all about simplifying Java EE.

Now Maven is the complete opposite of this. Why do I have to go and read their manual everytime I want to creating a project. I mean there is no way I will remember all that crap and their documentation is pretty appauling to begin with.

I think only Java people would be willing to accept a build system like Maven with all its complexities. Any other community would be like "what the hell is this?". For me Maven is the EJB2 of build systems: over complicated, over engineered and requiring an intelligent, code generating IDE just to work with it.

Having said all of that there are a good number of companies adopting Maven (god help them) and so I am not against having Maven support in Grails, but not by default. Arnaud from Octo has put together the excellent Maven Tools for Grails project, which allows you to create a POM for a Grails application and integrates Grails with the Maven lifecycle. Maybe one day we will include it in Grails core by default as an optional extra if Arnaud is interested in that.

However, I feel there is no use putting Maven in by default, because I strongly believe that in the long term it will be replaced by better tools like Gant, Raven, or Buildr.

Relevance on Grails vs Rails Architecture

Oh I love these back and forth posts, as a follow-up to their original thoughts on my last post, Relevance have put up one called "How to pick a platform". Unsurprising, they choose Rails over Grails for the case where there is no legacy "baggage".

Since they're a Rails company (althouth this may change given they've hired 2 guys from the Groovy/Grails community ;-) this isn't really surprising. The conclusions are that Rails' architecture is better because:

• Ruby is a better language than Groovy.
• Spring does most of its heavy lifting in the stable layer, which is not the right place.

So let's deal with these one by one. First, the whole "Ruby is better than Groovy" deal, this in my view is subjective and not worth arguing. Ruby has some nice features, and so does Groovy. If you come from a Perl background you'll probably like Ruby's syntax. If you're a Java guy, Groovy is pretty nice.

Stu's, second point is somewhat confusing and contradictory. He link's off to this post by Ola Bini where Ola says and I quote:

"The first layer is what I called the stable layer. It's not a very large part of the application in terms of functionality. But it's the part that everything else builds on top off, and is as such a very important part of it. This layer is the layer where static type safety will really help. Currently, Java is really the only choice for this layer. More about that later, though."

Later Ola goes on to say that Java is no good for the stable layer either and that another statically typed language like Scala would be better, but at no point does he say that a dynamically typed language is good for the stable layer.

Since Rails is 100% Ruby and, according to Ola Bini (JRuby committer) its not a good idea to build "the stable layer" in a dynamically typed language (Ruby) who has the better architecture?

Grails where the stable layer is built on powerful, stable and performant Spring or Rails where the stable layer is in Ruby, which is dog slow and problematic. I'll let you decide.

Personally, I don't buy into Ola's problems with Java for this so called stable layer nor do I believe that a dynamic language can't be used, at least in part, in the stable layer, because 25% of Grails' "stable" layer is written in Groovy. However, what I will say is Relevances' 2 conclusions are complete nonsense and fall into the "Crap" category of their original post.

What I advise anyone trying to make this decisions is download and try out both frameworks and use what suits you and your company. Every business is unique and not every framework is suitable for every business need. Don't buy into nonsense from either Stu or I that ones architecture is better than the other without comparing how it fits into your own existing architecture.

Grails Making Java Developers Forget about Rails

In 10 reasons to switch from Rails to Grails

Here is another 10:

1. A view technology that doesn't suck
2. Mixed source development made easy with the Groovy joint compiler (no falling back to C to solve those performance problems ;-)
3. Built in support for rich conversations with Web Flow
4. Grails 1.0 coming out within the month
5. IntelliJ's JetGroovy Plug-in
6. A rich plug-in system that integrates Grails with technologies Java people care about like GWT, DWR, JMS etc.
7. A buzzing and growing community with a larger traffic mailing list as opposed to a stagnating one
8. Built on Spring, the ultimate Enterprise Application Integration technology
9. A Service layer with automatic transaction demarcation and support for scopes
10. More books coming and being adopted by enterprise organisations near you

Update:

The Relevance guys have chipped in! They've gone ahead and neatly organised my points, good job. Let's deal with the ones under the "Crap" section:

Grails 1.0 coming out -
Ok fair point not a reason to choose Rails over Grails, unless stable release numbers is an issue for you

Built on Spring -
To put this one under crap sadly misses the point by a million miles. Rails has zero enterprise penetration, let's put that out there right now. Grails on the other hand has enterprise penetration and is only growing. A large part of this is the Spring toolkit which solves more enteprise problems than you can shake a stick at.

The comments on the Relevance blog back this up. Rails' attitude of openly shirking the enterprise has left a big gaping whole that Grails is happily filling. And finally for a Rails guy to call Spring a leaky abstraction is a little rich.

A Buzzing and Growing Community -
I'm not arguing that Rails has a smaller community, merely that it has plateaud, whilst Grails has no where near reached that point and has the potential to go much much further. Watch this space.

More books coming -
See above, even though I don't regard Grails as second best now for those that think that we won't be second best for long trust me ;-)

Groovy & Grails Happenings in the New Year

First let me say happy new year to all readers. I myself have just got back into the swing of things after spending some family time over in Spain.

It is nice to get back and see that even though with the holiday period the good stuff coming out of the Groovy and Grails community doesn't stop.

First up we have the announcement from the Pragmatic (almost mistyped that Programmatic!) Programmers that, shock/horror, they don't just do Ruby books, but have announced 2 new Groovy books: Groovy Recipes by Scott Davis and Programming Groovy by Venkat - thee of the unpronounceable surname ;-)

Next, for those of you who haven't been following Glen Smith's exploits in producing his Grails based blog called Gravl, checkout the latest screencast its looking really awesome. In the spirit of consuming ones own dog food, once he has done I may well migrate to Gravl!

Finally, the Grails user community continues to be busy with new plug-in releases and so on. The most significant of which is James' (who has also built his on Grails based blog) Google Chart API plug-in which looks really nice and Andreas' RichUI plug-in which adds a whole bunch of new tags to create rich components like tabbed panes, tag clouds, tree widgets to name just a few. Most of the components seem to take advantage of the Yahoo UI JavaScript library. Neat stuff.

As for the Grails 1.0 release we were supposed to ship that by the end of the year, but with the Groovy release coming a bit later and our aims to deliver a really high quality to release we decided to push it back a bit. The target is this month sometime so stay tuned.

SAP announces Composition on Grails 1.0

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

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


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

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

Grails at the Spring Experience

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

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

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

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

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

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

RE: Groovy in Ruby: Implement Interface with a Map

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

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

The Ruby code demonstrated is as follows:

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

Which then can be used as a method like:

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

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

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

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

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

1. { println 'foo' } as Runnable

And it can be extended by implementing the asType method.

The most entertaining quote however is this one:

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

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

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

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

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