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.