Graeme Rocher's Blog

Moved

2012-01-05T09:04:00.001Z

Grails 2.0 Released!

2011-12-15T16:56:00.001Z

Long time no post, but after lots of hard work from the Grails core team we are pleased to announce the Grails 2.0 release.

I have posted a comprehensive announcement on the SpringSource blog.

Enjoy!

Grails on Cloud Foundry

2011-04-13T09:07:00.003+01:00

For those of you who missed it, yesterday we launched the new Cloud
Foundry which we hope will become the premier deployment model for
Grails (and Spring, Ruby, Node.js etc.) applications in the the
future. If you missed the presentation checkout the YouTube recording.

It represents the culmination of a huge amount of work within VMware and we're super excited about the potential it has to completely revolutionize deployment models for Grails applications in the future.

Here are some further resources specific to Grails users:

Website: http://www.cloudfoundry.com/
Wiki & Sample applications: https://github.com/SpringSource/cloudfoundry-samples/wiki/Grails

Tutorial: http://blog.springsource.com/2011/04/12/one-step-deployment-with-grails-and-cloud-foundry/
Plugin Documentation: http://grails-plugins.github.com/grails-cloud-foundry/docs/manual/index.html

Signups are currently on a first come first serve basis under a limited beta programme.

Reading i18n messages from the database with Grails

2010-04-16T13:41:00.006+01:00

In a recent consulting engagement, a client wanted to know how to go about reading i18n messages from the database rather than static properties files (the default in Grails). Considering how easy this is to do I was surprised when I Googled it that there was no information on how this is achieved.

Anyway it's dead simple. Just create a domain class that models a message:

class Message {

String code

Locale locale

String text

}

Then implement a class that extends the org.springframework.context.support.AbstractMessageSource class. In the example below I am using simple GORM finders to lookup a message using the code and locale

class DatabaseMessageSource extends AbstractMessageSource {

protected MessageFormat resolveCode(String code, Locale locale) {

Message msg = Message.findByCodeAndLocale(code, locale)

def format

if(msg) {

format = new MessageFormat(msg.text, msg.locale)

}

else {

format = new MessageFormat(code, locale )

}

return format;

}

Then wire it in using Spring by configuring a "messageSource" bean in the grails-app/conf/spring/resources.groovy file:

beans = {

messageSource(DatabaseMessageSource)

}

And that's it. Now you're serving messages from the database. Of course this is a terrible inefficient implementation since we're hitting the database for ever message code used in the application. However, it's pretty easy to introduce caching. Just create a cache key:

@Immutable

class MessageKey implements Serializable {

String code

Locale locale

}

Then configure an appropriate cache bean (I'm using Ehcache) in Spring and wire it into your MessageSource:

beans = {

messageCache(EhCacheFactoryBean) {

timeToLive = 500

// other cache properties

}

messageSource(DatabaseMessageSource) {

messageCache = messageCache

}

Finally, update your implementation to use caching:

class DatabaseMessageSource extends AbstractMessageSource {

Ehcache messageCache

@Override

protected MessageFormat resolveCode(String code, Locale locale) {

def key = new MessageKey(code,locale)

def format = messageCache.get(key)?.value

if(!format) {

Message msg = Message.findByCodeAndLocale(code, locale)

if(msg) {

format = new MessageFormat(msg.text, msg.locale)

}

else {

format = new MessageFormat(code, locale)

}

messageCache.put new Element(key, format)

return format

}

return format;

}

Grails - dependency resolution done right

2009-09-17T20:23:00.004+01:00

Over the past couple of weeks I have been working on improving Grails dependency resolution capabilities for both applications and plugins. In previous versions of Grails (1.1 and below) you had limited options when it came to dependency resolution.

You could use the Grails Maven plugin, but that forced you to use, heavin forbid, Maven. We also shipped with basic Ant + Ivy support, but it was only really designed to be used for automation with continuous integration servers that support Ant and not at development time.

With Grails 1.2 this all changes with the introduction of Grails' dependency resolution DSL, which you can use to define your dependencies. Built on Ivy we have now eliminated one of the last remnants of XML usage in the Grails framework:

    dependencies {
      runtime 'com.mysql:mysql-connector-java:5.1.5'
      test 'junit:junit:3.8.2'
  }

Grails takes application defined dependencies (defined in grails-app/conf/BuildConfig.groovy) and merges them with dependencies defined in the framework or any installed plugins. If there are conflicts you can exclude dependencies inherited from the framework or you can override plugin dependencies.

By default Grails will only resolve dependencies against your Grails installation but you can enable remote repository resolution easily:

repositories {
      mavenCentral()
mavenRepo "http://repository.codehaus.org"
}

If you're addicted to your pom.xml file then we have even added the ability to read dependencies from the pom.xml instead of using the DSL. All in all, Grails 1.2 will give you significantly better control over dependencies and how they are resolved.

We're still on track to release Grails 1.2 by the end of the month, but if you want to hear more about it I'll be talking about Grails 1.2 at upcoming events such as JAOO (Denmark), SpringOne2GX (New Orleans, USA) and the Grails eXchange (London). See you there!

Grails 1.1.1, Gr8conf, AppEngine and other happenings

2009-05-21T12:41:00.002+01:00

Just got back from Gr8conf and really had a blast. It was a nice small group of 90-100 which meant you could really have a lot of one on one time with many of the attendees who had questions. The sessions were also not too short. Having that extra bit of time to elaborate on things makes a real different compared to the 45 minute rush you have at JavaOne et al.

All in all it felt more like a No Fluff event, which can only be described as a good thing. Right before the conference we released Grails 1.1.1 which is mainly a bug fix release, but the exciting part is the new Google AppEngine plugin which works with Grails 1.1.1

The plugin takes the heavy lifting out of configuring a Grails application for usage on AppEngine by automatically configuring the AppEngine development environment and a JDO persistence layer (JPA is coming too soon). You get reloading out of the box too, so Grails + AppEngine is really the most productive environment for developing JVM applications for AppEngine.

One missing feature from the AppEngine support right now is GORM (you have to use the raw JDO APIs). However, we are hard at work developing GORM-JPA (and potentially GORM-JDO) which will bring most of the features of GORM on top of standard JPA.

GORM-JPA is not the only exciting thing happening right now in the Grails plugin front. We are working with Adobe on integrating Flex and BlazeDS closely with Spring. The results of that can be seen in the recent Spring/BlazeDS integration 1.0 Rc2 release. The next phase is to build on top of that for the Grails plugin which is on my todo list to complete soon. Exciting times.

The plugin community itself continues to flourish, checkout these:

It is now finally possible to write Grails applications for different Portals such as Liferay and Pluto thanks to the Portlets plugins.
There is an excellent new plugin that embeds an LDAP server into Grails for easily testing LDAP
The Flex Scaffold plugin let's you generated complete CRUD applications using Grails and Adobe Flex
The Build Test Data plugin let's you quickly create dummy test data
Using the Spring WS plugin writing SOAP web services, feels more like writing REST service. Easy and painless.

These are just a few isolated mentions, there is activity going on all the time on the plugin space.

Grails 1.1 Released

2009-03-10T17:23:00.002Z

Yes! Grails 1.1 is out and available for download. Checkout my blog post on the SpringSource team blog for a more detailed overview of the highlights. It is a strange feeling after a release goes out, like a mixture of relief, happiness and that "ok what now" feeling. Maybe I take software too seriously :-|

Nice to see how Twitter is abuzz with the news (note live results, link will change overtime) right now. Other than that we are now planning the launch of the Grails.org plugin portal. To support that I have been writing a few plugins for Grails. It is niceto actually write Grails apps/plugins rather than work on the internals all the time.

Anyway the result is 2 new plugins called Commentable and Taggable that allow you to generically tag and comment on domain instances. I also have a new blog plugin in the works which will power the new Grails.org blog when that is ready. Actually its already available, but I need to document it better, and I'll save that for another post.

As for beyond Grails 1.1, we are now at the planning phase, but there are loads of things we are considering from OSGi to JCR to Cloud computing. Exciting times.

Grails at the London Java WUG

2009-02-11T10:57:00.002Z

I'll be doing a talk at the London Java Web User Group on Building Twitter with Grails in 40 Minutes on Monday the 16th of February. If you want to come a long you need to register ASAP, the last talk I did we had to turn away people as we could only fit 70 in the room.

See you there!

Grails Happenings: 1.1, Wired, Book etc.

2009-02-11T09:46:00.002Z

Regular readers, I must apologize for the relative lack of updates compared to 2008, but it seems I have caught the Twitter bug, where you can get more frequent ramblings of my activities.

Nevertheless, we are progressing well with Grails 1.1 which should be out this month. Loads of exciting stuff is on the way and I am really happy with what we have achieved. The Groovy 1.6 + Grails 1.1 combination is going to be a great one.

In other news we (SpringSource) have done a case study with Wired.com about their usage of Grails. We hope to put out more case studies and white papers in the future about Grails for those looking to convince their managers that Grails is the way to go. You can download the case study here.

In other news InfoQ has a nice article up about Grails and Dynamic Jasper. For thsoe of you who don't know, InfoQ are also the organizers of QCon, which I will be speaking at in March. I'll also be doing a half day Groovy/Grails workshop at the JavaOne University this year if you're looking for a more comprehensive engagement.

Finally, Jeff and I completed The Definitive Guide to Grails, Second Edition which is a complete re-write (and a heftier one at that) of the original book with up-t0-date information covering Grails 1.0 and many of the features of Grails 1.1.

Grails & Maven Kiss and Make-up with Grails 1.1 Beta 2

2008-12-23T13:50:00.003Z

So Grails 1.1 Beta 2 is out. Rejoice! There are many new features that are detailed in the release notes. However, one of the main ones in this beta is the new support for Maven.

Regular readers of my blog will probably be aware of my long history as one who, ahem, is not particularily fond of Maven. Granted I am still not particularily fond of Maven, but it is the Christmas period and in the spirit of "why can't we all just get a long" I am proud to say that Grails integrates nicely with Maven now :-)

Peter Ledbrook, core Grails committers, has been tirelessly working away at making the Grails + Maven experience a seamless one. I personally even went as far as installing Maven 2 onto my machine, which was a huge jump for me I can tell you, and I can tell you Peter's done a great job!

As ever we encourage Maven users to give the Maven integration a go and report any issues that you may have with it in JIRA. Enjoy!

Grails + Spring Integration

2008-12-09T23:31:00.003Z

Regular readers will recall I mentioned in my announcement of the SpringSource acquisition of G2One that the potential to integrate Grails with more Spring portfolio products is huge. Well, SpringSource colleague Russ Miles has taken the first steps in integrating Grails with Spring Integration 1.0.

For those of you who don't know, Spring Integration is a lightweight way to do message passing through endpoints in a similar way to some of the big ESBs. The article is a precursor to even more exciting stuff involving Spring Integration being made available as a Grails plugin. Watch this space.

Interview with me on Grails Podcast

2008-11-25T17:06:00.002Z

Those crazy guys over at the Grails podcast interviewed me about various things ranging from being part of SpringSource to the upcoming Grails 1.1 release to my deep hatred of all things Maven. Check it out.

Groovy and Grails join the Spring family

2008-11-11T09:12:00.004Z

You may have already read about it in the various news outlets and blogs covering the announcement, but if you haven’t I’m excited to spread the word that G2One - The Groovy/Grails company - has been acquired by SpringSource. The result is that Groovy and Grails join the growing number of excellent Open Source projects delivered by SpringSource.

The Spring Framework really pioneered simplified development on the Java platform. A philosophy that is the very essence of Grails. Both frameworks aggressively try to makes the lives of developers easier. The Spring Framework provides an abstraction layer of common Java enterprise APIs, whilst Grails uses the Groovy dynamic language to further simplify Spring and Java. In this sense Grails fits perfectly into SpringSource’s philosophy.

On the Grails front this is great news at multiple levels. With Grails already being based on Spring, users of Grails now have access to expertise about not only Grails, but also Spring, the framework that underpins all of Grails. Grails will benefit further from tighter integration with the Spring Framework with exciting integration possibilities on the horizon between Grails and great Spring portfolio products like Spring Batch, Spring Integration and SpringSource dm Server.

Grails will benefit from greater visibility and wider adoption simply by being under the SpringSource umbrella. In addition, SpringSource will bring all their expertise around Eclipse plugin development ensuring that users of Groovy and Grails have a first class experience in the Eclipse IDE.

At SpringSource, there is a lot of excitement about Groovy and Grails. Grails adds that little bit of Web 2.0 spice to the company and provides yet another avenue for users to adopt the Spring Framework. We’re literally buzzing with ideas on how Spring, Groovy and Grails can be integrated in the future and look forward to the feedback of the respective communities.

I personally will continue to lead Grails at SpringSource, whilst Guillaume remains the project lead of Groovy. The majority of the former G2One team have taken up positions at SpringSource. On the topic of Guillaume, he is as excited about this development as I am and has a great post on the benefits of the acquisition to Groovy. Check it out!

Resources:

Couple of nice Grails UI articles

2008-11-03T14:10:00.001Z

Matt Taylor has posted a couple of nice articles demonstrating how to use GrailsUI's dataTable component. Cool stuff.

GrailsUI 1.0 Released

2008-11-01T11:25:00.002Z

Over the past few months we've had a lot of demand from different clients for a UI component library for Grails, built and supported by G2One. Thanks to a great collaborative effort, GrailsUI 1.0 is now available built on the excellent Yahoo UI library.

Matthew Taylor, G2One Software Engineer and the lead of the GrailsUI project, has the lowdown on what is on offer. Check it out!

New GORM Features Coming in 1.1

2008-10-31T08:48:00.011Z

Now that The Definitive Guide to Grails 2nd Edition (barring a few reviews) is a wrap, I've been refocusing in Grails development. First up, is GORM and we've implemented a number of great improvements including:

Better GORM events

Previously, GORM supported beforeInsert, beforeUpdate and beforeDelete events, now there is afterInsert, afterUpdate and afterDelete to complete the picture

Persistence of Collections of Basic Types

GORM now supports persisting basic types like String, Integer and so on using a join table:

class Person {
   static hasMany = [nicknames:String]
}

Improvements to Data Binding

It is now simpler to bind data to a subset of properties. Previously you could use the syntax:

person.properties = params

Which would bind all the incoming request parameters to the person. If you didn't want that behavior you could use the bindData method. Now you can bind to a subset of properties using the subscript operator:

person.properties["firstName","lastName"] = params

And access a subset of the domain classes properties using the same syntax:

person.properties["firstName","lastName"].each { println it }

Read-Only Access to Objects

Persistent instances can now be loaded in a read-only state using the read method:

def book = Book.read(1)

Default Sort Order

Associations can now be sorted using a default sort order declared at the class level:

class Book {
String title
static mapping = {
     sort "title"
}
}

Or at the association level:

class Author {
    static hasMany = [books:Book]
    static mapping = {
              books sort:"title"
    }
}

Batch Fetching

GORM now supports configuring batch fetching (an optimization of lazy loading) using the ORM DSL at the class level:

class Book {
String title
static mapping = {
     batchSize 15
}
}

Or at the association level:

class Author {
    static hasMany = [books:Book]
    static mapping = {
              books batchSize:15
    }
}

Improvements to Dynamic Finders

There is a new InList suffix that can be used with dynamic finders:

def groovyBooks = Book.findByAuthorInList(['Dierk Koenig', 'Graeme Rocher'])

Dynamic finders can also now use the query cache:

def books = Book.findByTitle("Groovy in Action", [cache:true] )

And upgrade to a pessimistic lock:

def books = Book.findByTitle("Groovy in Action", [lock:true] )

Legacy Mapping for Many-to-Many and Unidirectional One-to-manys

Many-to-many and Unidirectional One-to-many associations can use the joinTable argument to alter the way they map to the underlying database:

class Book {
 String title
 static belongsTo = Author
 static hasMany = [authors:Author]

 static mapping = {
     authors joinTable:[name:"mm_author_books", key:'mm_book_id' ]
 }
}
class Author {
 String name
 static hasMany = [books:Book]
 static mapping = {
     books joinTable:[name:"mm_author_books", key:'mm_author_id']
 }
}

Sky.com relaunches written in Grails

2008-10-02T09:39:00.005+01:00

The main portal for Sky television has relaunched written in Grails. Sky, also known as British Sky Broadcasting or BSkyB, employs 17000 people in the UK and operates the largest satellite network in the UK.

The site receives a million+ hits per day and joins all the other subsites also written in Grails:

Congrats to the Sky team!

Update 07/10: Couple of new things have arison since this was posted. Firstly, Sky actually employ 17000 people not 11000. Seems the Google sample data I obtained was out of date.

Also Glenn Saqui has a nice write-up on the architecture of Sky.com on Marc's Blog. Altogether the 4 subsites listed above receive over 110 million hits per month and run on a cluster of web layer machines and 2 db machines. Checkout the aforementioned link for more info.

Terracotta meets Grails with the Terracotta for Grails plugin

2008-09-02T09:34:00.002+01:00

Our busy community of plugin developers have been at it again and now there is a brand new plugin for Grails that adds support for the Terracotta data grid. It was always possible to do this with a bit of manual configuration, but now the plugin automates things nicely using a few new Grails command line scripts.

This is one of the really great things about Grails and Groovy, because Groovy classes are just standard Java classes it is possible to integrate Groovy or Grails applications with any existing Java infrastructure, including data grids like Terracotta and Coherence. Awesome stuff.

Groovy/Grails Community goes wild launches two sites

2008-09-01T10:31:00.003+01:00

Wow, the Groovy/Grails community is really getting it together. First we had the launch of grailscrowd.com, which is a social networking site for Groovy/Grails people to connect with other Groovy/Grails people. The site is built on Grails and its only been up for a few days but aldready over 600 people registered. If you haven't done so do so! The source code for GrailsCrowd is also availabe at Github

Not to be outdown, however, Glen Smith has launched the Groovy Awards ! A site dedicated to nominating the best contributors and to the Groovy / Grails community. Awards up for grabs include Groovy / Grails t-shirts and other goodies. Check it out.

On my front, I know I have been rather inactive posting. Books are really all consuming beasts. I have given a go to twittering now and again about what I'm writing about, although I'm still not sure I "get" twitter.

London Groovy/Grails User Group Meeting - 31st July 2008

2008-07-28T17:03:00.002+01:00

I'll be giving a talk on the state of Grails at the London Groovy+Grails user group meeting on the 31st of July. Skills Matter are hosting it as usual, be sure to sign-up here.

Groovy/Grails Training in North America

2008-07-14T15:44:00.002+01:00

Apologies for not posting as frequently recently, I've been hard at work on the second edition of "The Definitive Guide to Grails" and also working on feature development for Grails 1.1 (we now have JSP tag library support in GSP and massive improvements to the plug-in system).

Nevertheless, on to the topic of this post, we (G2One In c - The Groovy/Grails company) have launched our public Groovy & Grails training programme in the US. Announcing this exciting news is Jeff Brown, our main guy in the US, who has this to say:

"Our training events are a fantastic experience. G2One are the folks who lead and sustain the development of both Groovy and Grails. No one understands the technology better than the people who build it. G2One training events give developers an opportunity to spend several days with a technology expert covering everything from fundamentals to advanced language and framework features.

The sessions include a perfect mix of lecture and reinforcing lab work. That hands on approach is a great way for developers to internalize the details. There is no better way to quickly get a team up and running with the technology."

Check it out!

Brian Guan on Grails at LinkedIn

2008-06-16T13:21:00.004+01:00

Brian Guan, one of the pioneers of Grails use within LinkedIn, has started a blog series about their experiences with Grails. The first post presents the slides the LinkedIn guys presented at the recent Groovy/Grails meetup at JavaOne. It makes for an interested read so check it out!

Grails 1.0.3 Released

2008-06-06T14:24:00.002+01:00

We've just released Grails 1.0.3, which includes 230 issues resolutions and improvements since the last release. The release notes go through the full details, including outlining some of the new features like enum support and interactive mode.

Grails has come a long way, since the release of 1.0 Grails has been downloaded over 186000 times averaging out to around 50000 times per month. That puts it on par or not far behind some of the biggest open source projects like Spring, Hibernate and Struts in terms of downloads.

The most exciting thing for me though is the plug-in community with over 70 plug-ins in the repository some of the new ones include Axis 2 support, Java2D with GraphicsBuilder and profiling (contributed by one of the biggest Grails users LinkedIn) and debugging plug-ins. Awesome stuff.

Now I'm shifting my focus to the second edition of the book, and feature development for Grails 1.1.

Groovy Grails Training From G2One and Callista Enterprise

2008-05-23T08:55:00.001+01:00

G2One, Inc. and Callista Enterprise AB have announced a partnership to support Advanced Groovy and Grails training in Scandinavia.

Göteborg 2008-09-08
Stockholm 2008-09-15
Malmö 2008-09-22

The 3 day comprehensive course covers details from intro to advanced for both the Groovy language and the Grails framework. The course description may be found here.

As with all G2One training events, students will receive a free 12 month license for IntelliJ IDEA. IDEA's JetGroovy brings fantastic support for both Groovy and Grails to the IDE.

Please contact us at training at g2one dot com with any training related inquiries.

Grails in Depth slides from JavaOne 08

2008-05-22T09:17:00.002+01:00

Although I wasn't able to make JavaOne due to my bought of pneumonia, Guillaume did an excellent job of delivering my presentations and then did everyone a favour by posting them online! Here we go for those who haven't seen them yet:

| View | Upload your own

Grails.org now powered by Grails

2008-05-19T12:35:00.002+01:00

We've just launched a re-write of the Grails.org site in Grails. Previously the site was powered by Confluence (the Atlassian wiki), now in the spirit of eating ones own dog food it is a fully Grails powered site.

Ever since the Seam guys launched seamframework.org powered by Seam I felt something had to be done, before we could look them in the face again ;-)

Now its there and its more than a simple page turner, but a full featured wiki engine including versioning, diff'ing etc. and the source code is available at Codehaus. Enjoy!

On missing JavaOne 08

2008-05-10T10:31:00.002+01:00

As I write this JavaOne 08 is being wrapped up and I am horizontal in bed. I somehow managed to get pleurisy and pneumonia a few days before the event so missed it completely.

Luckily, the awesome Guillaume Laforge delivered my talks on Groovy and Grails instead of me, but sorry to those who were expecting to see me there, health comes first in this case.

It seems to have been another successful conference from what I could infer from the twitter feed and various blog postings. Was nice to hear Groovy in Action was 3rd and The Definitive Guide to Grails 6th of the best seller list after day 1.

On that topic of the books, being bed bound for a couple of weeks has given me the chance (when I'm not sleeping and feeling too ill) to spend some time planning and writing the second edition of the "The Definitive Guide..".

I'm co-authoring with Scott Davis, so the book should be bigger badder and more impressive this time. Target release date is the end of the year. Lets hope the codene doesn't make my ramblings to incoherent!

Spring Application Platform and Grails

2008-05-01T10:45:00.003+01:00

For those of you interested, Grails applications deploy and execute on SpringSource's new Application Platform without any issues. I have updated the Grails deployment page to that effect.

Grails wins second prize at JAX awards

2008-04-26T17:47:00.002+01:00

Great to hear that Grails won second prize at the JAX innovation awards, Guillaume was there to accept the award as I was away on annual leave in Thailand.

Would have been nice to win first prize, but since Groovy won last year I guess that would be too much to expect :-)

There is a remarkable amount of innovation going on within the Grails community itself, just in the past week or so we've had new releases of the Selenium plug-in, the JSecurity plug-in, a JAWR plug-in, an OpenID plug-in and the new simple Authentication Plug-in.

All contributed by our awesome user community. Amazing.

Choosing an OSS License and the Ext-JS saga

2008-04-25T15:45:00.003+01:00

The news that Ext-JS has, from one release to the next, changed from a modified LGPL to a GPL based license nearly made me fall off my chair. There have been many poor judged, and ill advised decisions made by software companies over the last few years, but this has got to be up there with the stupidist I've seen and I'm not even personally an Ext-JS user.

What they have effectively done is built up a community, taking full advantage of the open source model by accepting user contributions and patches and then turned around and kicked their own community up the backside. It is projects like Ext-JS that give open source a bad name. How can a company have faith in open source if the people behind it can't even decide how to license the thing?

When you start off in the software business you have to very early on decide whether you are an open source company or whether you are a commercial software company. If you choose the former then you need to choose an appropriate license. For platforms the GPL license can make a lot of sense (think Linux and Java) to prevent forks, force contributions etc. although I'm still not a big fan of it.

On the otherhand for libraries or frameworks only a few licenses make sense (Apache 2.0, MIT, BSD and to a lesser extent LGPL). With Grails we went for Apache 2.0 as one of the most liberal licenses out there. Once you've decided on the license as an open source company your job is the grow the community by attracting users who put faith in your product and the fact that its licensed in a liberal way. Those users would not come in the first place if you had a restrictive license.

By choosing the open source route you have made a decision as a company to promote the community driven approach. Of course this doesn't stop you from releasing a commercial version, you could dual license it as Ext-JS have done for those who want the comfortable feeling of paying for something. You cannot however, have it both ways you are either an open source company or you are not. Ext-JS seem to be stuck in 2 minds as to whether they really are an open source company, it is this indecisiveness that is going to see their community go elsewhere.

It is not like they're unique either, the Ajax framework space is super competitive and they've just dropped the ball and given their competitors a big advantage. My personally prediction on this one is that they'll lose a lot of users, probably to Yahoo UI and jQuery UI or possibly Dojo. Something else will soon come along to fill their space and soon they will have lost their competitive advantage, their users and all those license renewals.

Large commercial Grails site goes live

2008-03-13T10:45:00.004Z

Sky (commercially known as BSkyB), who are the biggest satellite broadcaster in the UK and largely owned by News Corporation (Rupert Murdoch et al), have re-launched their Sky showbiz news portal, powered by Grails.

The site was put together by energizedwork, a consulting firm in the UK, well done guys!

This represents one of the largest, commercial public facing Grails applications (that we at G2One Inc are able to talk about at least ;-) out there at the moment with traffic in the region of 186 million page views a month. Its great to see so many huge companies taking the leap to Grails, long may it continue!

Grails at JavaOne & CommunityOne 08

2008-03-13T10:19:00.002Z

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

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

2008-03-12T18:47:00.000Z

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

Groovy is Java AND Groovy is not Java

2008-03-11T15:04:00.005Z

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

2008-03-06T11:36:00.003Z

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

2008-03-05T10:49:00.002Z

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

2008-02-25T12:37:00.003Z

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

2008-02-25T12:12:00.002Z

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

2008-02-25T11:04:00.009Z

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

2008-02-12T11:29:00.000Z

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!

2008-02-05T10:54:00.000Z

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?

2008-01-18T14:05:00.001Z

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:

Call shell.evaluate("x = 100")
Call System.gc()
Thread.sleep(1000)
Record used memory
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

2008-01-18T09:34:00.001Z

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

2008-01-16T16:54:00.000Z

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

2008-01-16T09:11:00.001Z

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

2008-01-14T10:24:00.000Z

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

2008-01-10T09:02:00.000Z

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

2008-01-08T12:42:00.000Z

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

2007-12-19T06:10:00.001Z

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

2007-12-15T20:17:00.001Z

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

2007-12-06T21:18:00.000Z

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.

On the road to Grails 1.0: An incredible amount of Grails stuff going on

2007-11-23T09:28:00.001Z

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:

It demonstrates how Grails can be integrated with existing Java frameworks to further enhance its capabilities. This is all down to Groovy's seamless integration with Java and Grails' extensible Plug-in system.
We now have Plug-ins that provide varying levels of integration for many of the significant Java based Ajax stacks such as GWT, Echo2, DWR, ZK, Open Laszlo and Dojo. All driven by our user community.

Other things of significance include the launch of 4 new public Grails based sites in the past month, including:

WorkBoard - A FaceBook application that provides classified ads
Food Tube - A London restaurant guide and booking service
FilmSuggestions.com - Catalogue your favourite films, commenting and tagging as you go
Job Insiders - A German Job rating community

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.

Grails Development with IntelliJ IDEA

2007-11-01T23:29:00.000Z

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.

Grails eXchange - The aftermath

2007-11-01T23:16:00.000Z

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.

Groovy Quote of the Day from Geertjan at Sun

2007-10-18T14:38:00.000+01:00

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

Grails 1.0 RC1, IntelliJ 7.0 & Grails eXchange Day 1

2007-10-17T22:57:00.000+01:00

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.

G2One: The Groovy/Grails Company is born

2007-10-10T14:30:00.000+01:00

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 Using Groovy & Grails, Release Grails-based Product

2007-10-09T09:24:00.000+01:00

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!

LinkedIn Looking for Groovy/Grails Developers

2007-10-05T09:08:00.000+01:00

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.

Refactr Interview Grails Dev Marc Palmer

2007-10-03T09:41:00.000+01:00

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

Grails at JAOO 07

2007-09-25T16:30:00.000+01:00

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

The new meta-programming APIs in Groovy 1.1 beta 3

2007-09-21T09:22:00.000+01:00

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 saying nice stuff about Groovy/Grails

2007-09-19T10:29:00.001+01:00

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.

David HH Living in Cloud Cookoo-land

2007-09-03T13:40:00.000+01:00

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

Grails 0.6 Released with Rich Conversation Support (AKA Spring Web Flow)

2007-08-31T14:37:00.000+01:00

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

Setting up an Apple Airport Exreme Router with Virgin Media set-top box

2007-08-20T13:13:00.000+01:00

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

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

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!

Grails Employment Oppurtunities

2007-08-04T22:48:00.000+01:00

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

Grails more Productive than Rails? Surely not you say?

2007-08-03T11:19:00.000+01:00

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:

Use an existing Hibernate domain model written in Java and still get the benefit of dynamic finders, persistence methods etc.
Re-use existing Spring services as Grails built entirely on Spring with all its enterprise application integration goodness
Leverage an array of enterprise proven technologies such as Sitemesh, Quartz, Lucene, Compass ... (this list could go on)
And in the upcoming 0.6 release, thanks to contributions from JetBrains, you can jointly compile Java & Groovy and have circular references between the Groovy and Java code (a Groovy class is just a Java class after all)

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?

Method missing in Groovy - Part 2

2007-07-18T15:48:00.000+01:00

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

2007-07-16T16:05:00.000+01:00

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

2007-07-06T15:09:00.000+01:00

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

2007-07-06T14:56:00.000+01:00

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

2007-07-05T21:24:00.000+01:00

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

2007-06-29T16:09:00.000+01:00

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?

2007-06-27T16:03:00.000+01:00

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

2007-06-22T18:05:00.000+01:00

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

2007-06-21T14:41:00.000+01:00

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

2007-06-14T08:25:00.000+01:00

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

2007-06-01T18:00:00.000+01:00

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

2007-05-17T15:29:00.000+01:00

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

2007-05-16T20:43:00.000+01:00

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

2007-05-14T11:54:00.000+01:00

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

2007-05-11T00:23:00.000+01:00

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

2007-05-10T07:13:00.000+01:00

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

2007-05-09T07:47:00.000+01:00

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

2007-05-08T16:00:00.000+01:00

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

2007-05-07T07:33:00.000+01:00

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

2007-05-04T09:50:00.000+01:00

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!

G2One at JavaOne: A Special Groovy/Grails Event

2007-05-02T09:12:00.000+01:00

Looks like this years JavaOne in San Francisco is going to be an even more exciting event than expected with a new Groovy/Grails specific event organised by Jay Zimmerman of No Fluff Just Stuff called G2One. Its a great oppurtunity to meet up with some of the people behind Groovy & Grails, but you have to pre-register! Only 250 places available and registration is free. With this event, all the other No Fluff activity in the US and Skills Matter's upcoming Grails eXchange 2007 conference, it seems Groovy & Grails are very well respresented in the conference stakes.

Grails 0.5 Shipping!

2007-05-01T18:04:00.000+01:00

A few days before we all converge on JavaOne 07 and Grails 0.5 is out! This is an awesome milestone for Grails and represents a significant improvement over Grails 0.4. Well over 200 JIRA issues have been tackled and Grails is now 40-50% faster than previously published benchmarks

We got round to tackling some great new features such as our DSL for URL mapping, command objects, more codecs and huge improvements to GORM. Take a look at the release notes for more info. All in all I feel Grails is coming along nicely and we are still on target to ship 1.0 by autumn. See you at JavaOne 07!

Groovy & Grails at JavaOne 07 University

2007-04-18T16:09:00.000+01:00

As well as a BOF at JavaOne I'll also be doing a half-day course at the JavaOne university on Groovy & Grails. Check it out here.

Neal Ford: "I would rather write Groovy code in VI than Java code in IDEA"

2007-04-18T10:26:00.000+01:00

Interesting and entertaining interview with Neal Ford of ThoughtWorks fame. He has lots of nice things to say about Groovy and Ruby.

The only point I disagree with is his assertion that in Groovy you can only do 80% of what you can do in Ruby in terms of DSL programming. I've never seen a Ruby DSL that couldn't be done in Groovy with a similar conciseness in the syntax. It would be nice if Neal could elaborate on this point.

Contrasting Grails SpringBuilder vs JRuby Spring DSL vs Guice

2007-04-17T09:12:00.000+01:00

An interesting post by Craig Walls that I hadn't noticed before shows how you can create Spring configs with a little JRuby DSL:



DAOS = [ :ZoneDAO, :EmailDomainDAO, :DayDAO, :PreferenceDAO,
                 :WhatEverDao... ]
DAOS.each do |dao|
    bean(dao, "daos.hibernate.#{dao}Hibernate")
      {|b| b.new("sonarSession")}
end

The Groovy version with Grails' SpringBuilder would look like:



def DAOS = [ZoneDAO, EmailDomainDAO, DayDAO, PreferenceDAO, WhateverDAO]
DAOs.each { dao ->
   "${dao}"("daos.hibernate.${dao.simpleName}Hibernate") {
       sessionFactory = ref("sonarSession")
    }
}

Another important difference between the two is that Springy, the JRuby version, serializes the JRuby code into XML and then reads the beans from that. We used to do this in Grails, but it had serious performance implications for load time, Grails' BeanBuilder constructs the ApplicationContext programmatically on the fly.

Bob Lee also offered his alternative using Guice:



Class[] daos = { ZoneDao.class, EmailDomainDao.class, PreferenceDao.class... };
for (Class dao : daos)
bind(dao).to(Class.forName("daos.hibernate.Hibernate" + dao.getSimpleName()));

Since Groovy does annotations it is possible to make this code even Groovier:



def daos = [ZoneDao, EmailDomainDao, PreferenceDao...]
daos.each { bind(it).to(Class.forName("daos.hibernate.Hibernate${it.simpleName}") }

Updated Grails vs Rails Benchmark

2007-03-24T15:56:00.000Z

So after a couple of people pointed out my naivety in configuring Rails, I decided to re-run the tests. What I did was configure Rails with a 10 mongrel cluster and the Pound load balancer as per Jared's recommendation. However, to make things more equal I reduced the Grails Tomcat server's thread pool down to 10 by setting maxThreads=10 in Tomcat's server.xml.

The result was that Rails' performance degraded in all except the long running query test, whilst Grails' performance significantly improved in all except the same test. Clearly, since I have only dual core's on my MacBook giving Rails or Grails more processes doesn't necessarily improve things for the shorter tasks. Check out the updated benchmarks.

Again, I'm no Rails performance tuning wizard so if any Rails expert can suggest improvements to the Rails configuration please don't hesitate to shout.

Grails vs. Rails Benchmark

2007-03-23T00:05:00.000Z

This article: http://thoughtmining.blogspot.com/2007/03/where-are-all-groovy-andor-grails.html

Prompted me to do this:
http://docs.codehaus.org/display/GRAILS/Grails+vs+Rails+Benchmark

Feedback welcome.

I must stress this is not meant to be a flame war inciting benchmark, it has been done merely to allay the aforementioned bloggers fear that he expresses in this comment:

"Surely someone close to the respective projects has asked these hard questions of themselves?

Because I know the previous paragraph has to, has to, be true, then I can only assume one thing: someone has done this as an exercise...and the results were depressing. Why else would the results not be published? If Groovy or Grails was faster, even slightly so, then you can bet it would trumpeted far and wide. The fact that it's not leaves an unsettling feeling."

Groovy & Grails at Sun Tech Days - The Report

2007-03-22T10:08:00.000Z

I've been meaning to write up a report of how my workshop on Groovy & Grails at Sun Tech Days went, so here it is. First off, I would like to say a big thanks to the guys at Sun for hosting me, it was great gesture and thankfully we'll see more of it at JavaOne.

As far as the workshop went, I really wanted to deliver something of value and probably ended up overdoing it as a I had over 160 slides (death by keynote!). Fortunately, the audience were extremely enthusiastic with the only hiccup being a gentlemen who was running a p3 450mhz machine with 256mb of RAM and Windows 98 (with MS-DOS!) not being able to get the Grails command line scripts running.

Interestingly, the majority of attendees were from either the banking or insurance industries, which reflects Grails' growth in the enterprise market space. There were many wow moments, and some concepts which were difficult to grok for a group of Java developers. Explaining closures was particularly fun.

Overall, the attendees seemed to enjoy the workshop and left brimming with ideas of how to integrate Grails into their existing systems. Job done.

Grails Interview on Groovy.org.es

2007-03-20T09:10:00.000Z

The nice chaps at Groovy.org.es were kind enough to take the time to interview me. For those who want to improve their Spanish and learn what's going on in the Groovy/Grails world check it out.

JRuby, Groovy & Java Integration

2007-03-13T13:57:00.000Z

As a follow-up to yesterdays article, I would like to point out the following article written by Ola Bini on the JRuby team: JRuby Regular Expressions.

This article represents everything that differs in the mentality between the Groovy & the JRuby teams. In essence, the JRuby team are planning on ditching java.util.regex and implementing their own regex parser to match the Ruby regex semantics.

Regardless as to whether this is a good thing or not, and regardless as to whether you can change the default implementation this is the essence of the debate over Java integration. So whenever you drop out of Java and into Ruby-land you need to remember that the semantics differ between regex implementations. To be clear: Java integration means more than just being able to call a method on a Java class.

To quote Dierk Koenig, author of Groovy in Action, who posted this comment yesterday:

"I would like to add that there is a fundamental difference between the two types of languages for the Java platform: type A, which are languages designed specifically for that platform (Groovy, Scala, etc.), and type B, which are ports of a foreign language (Jython, JRuby, Kawa, Bistro, and the likes).

While type B languages can achieve a decent level of interoperability, only type A languages can truly integrate with Java. This is because foreign languages not only have their own libraries, APIs, and such but more important, they come with their own object model, threading architecture, security concept, performance and debugging hooks, and last not least their own runtime architecture that can be fundamentally different from Java. Any type B language has to overcome this impedance mismatch breaking either Java's or the foreign language's behavior.

The acid test for integration is to replace any given Java class (be it abstract, or in the middle of an inheritance chain, or having overloaded methods, or using annotations) and replace it with an implementation in your language. This is what only type A languages can possibly achieve."

In other words, this is another example of how the JRuby developers have to make a hard choice in order to support C Ruby compatibility. Unfortunately on this occasion, it is Java integration that suffers.

In Groovy the expression ~/pattern/ results in an instance of java.util.regex.Pattern therefore the semantics are the same, you can call all the regular JDK methods on the object and the object can be passed to a Java object to hook into other frameworks and tools.

The Charles Nutter Ruby on Grails story

2007-03-12T09:33:00.000Z

Back in December Charles Nutter and I had a discussion at JavaPolis about collaborating and the potential to leverage Grails as a platform for multiple languages.

Now Charles has actually looked at the codebase, and would even like a further extended tour (Charles - give me a shout if you're interested, I'd be happy to). His conclusion? Lets make Ruby on Grails. I don't find it particularily suprising he has come to this conclusion. His estimates of Java-to-Groovy are actually way off. I would say if you take away the unit tests and sample apps, Grails is more like 85% Java. There are a few things that should be pointed out here:

Not only is it very possible to support other languages, it is feasible now, thanks to the plugin system and Grails' well thought out, as Charles puts it, "interfacified, injectificated, and abstractilicious" design.
The benefits of leveraging all of the existing dominant libraries in the Java eco-system (Spring, Hibernate, SiteMesh, Quartz) is becoming more clear. There is no doubt that the codebase and libraries being in Java provide a significant performance improvement over Rails (100% Ruby) in my view. Grails is a mere Groovy facade onto a well integrated set of libraries, I've been saying this at ever presentation I've given about Grails since day one. This is one assertion Charles is most certainly correct on.
We also see these same benefits for people who need a reasonable migration path. Questions like "how can I use my existing Hibernate domain model?", "Can I continue to use Spring MVC controllers?", and "Can I inject and re-use Java services?" all have a clear and well defined answer in Grails making it much easier (although still challenging) to sell into enterprise organisations.

So back to the original question then, the answer is a most resounding "yes!" we could most certainly support multiple languages. But, before we get too excited lets get back to reality. Creating simple web frameworks is simple, creating tightly integrating, elegant, user-friendly frameworks is hard.

With Grails we've embraced the Groovy language idioms like builders, closures and meta-programming in a big way. We've pushed the boundaries of what Groovy is capable of doing. Now say we decided to support JRuby, and maybe JavaScript could we create as elegant a framework by making compromises to support all language idioms? Actually, in this case yes we probably could because Ruby for example as Charles says in his typically "language neutral" way "everything you can do in Groovy you can do in Ruby (plus more)". But how long would that take?

Then there is the Java integration story, which I believe Charles is only getting half of the picture here. Java integration is not just about being able to invoke a method on a Java object. Java integration is about mindshare integration, API integration, syntax integration, object model integration. JRuby has only just managed to solve object model integration, it won't ever be able to solve API, syntax or mindshare integration. What I mean by this is when i create a File, it should be a java.io.File, what about Streams do I forget about those? And the Collections API? Out the window with JRuby. Hang on, when I'm in "Ruby-land" a string isn't a java.lang.String? Telling an organisation that they're going to have to send their entire development team on weeks and weeks of training to understand Ruby and Rails is a hard sell. As Chad Fowler said recently at RailsConf, Ruby is not for "stupid programmers", which effectively means you need well trained people.

And of course then there is Agile and scalable application complexity. Dynamic languages are only useful for small to medium complex applications. This is also "fact". Having supported a multi-tier Perl system for a number of years I would rather die than have to write a complex banking system completely in Groovy or Ruby. But, I would be quite happy to write parts of it in either. If you take this approach you get what I call scalable complexity. The ability to start off in a dynamic language and when things get tricky implement certain parts in Java.

The problem here is that to take this approach you need two languages (one dynamically-typed, one statically-typed) that work seamlessly together. Why? In Agile one of the activities known to reduce productivity is task switching. Read any book on Lean Thinking and Agile and they'll tell you to eliminate waste by eliminating task switching. Switching language idioms is task switching and in this sense the Java-to-Groovy story is just so much stronger. A developer can easily switch between using Java and using Groovy without having to start thinking in a completely different way. This is simply not the case with JRuby.

On the practicality front, Grails 1.0 will be out by Autumn (that's Fall for those on the other side of the pond) or maybe even sooner. By supporting all these languages we'd end up in a situation like Phobos, which is basically going nowhere and does not do a quarter of what Grails or Rails is capable of.

So does all this mean I don't want to support Ruby on Grails? Hell, I would love if we could! Choice is a good thing and with the JVM this is completely possible, its just down to the old conundrum: Resources. So maybe Sun should, instead of wasting their time with dead end projects like Phobos, step up to the plate and commit resources to projects that do matter now. Like Grails.

So why should Sun do this? Well, Grails is beginning to win the battle for the hearts of minds of Java developers looking for the next big web framework. How can I justify this claim?

We have had a huge surge in popularity, Groovy in Action is the number one best selling book at Amazon "Java Books"
There are 12 sessions featuring Groovy and/or Grails at JavaOne.
Grails is the most popular project at Codehaus.org by a long way.
Over at JBoss they're scrambling around attending GroovyDevCon meetings and looking to get Groovy incorporated in Seam to bring the same level of elegance to Seam as we have now in Grails. Still, I believe JBoss are on to a good thing, keep up the good work guys ;-)
JRuby on Rails is being talked about, and noise is being made, but where is the real world use cases? Who is actually deploying JRuby on Rails now? No one. fact. With Grails we have people using and deploying real worlds Grails applications all over the place. In the Java space, JRuby on Rails is playing catchup to Grails and not the other way round. And now we have JRuby on Grails being suggested. How the tables are turning ;-)
Then we have poor old Phobos, which has managed 38 posts on the user mailing list since June last year. As Charles says, you guys are "damn smart" Sun engineers, so do the smart thing and give up guys, this is going nowhere. On one side of the fence you're saying "use JSF and forget about Javascript!" and now you want people to write it on the Server-side? I love JavaScript, but there are far more elegant languages to include on the server-side. My advice? Join Grails and help make it better and support other languages. We have solutions to most of the problems you're trying to solve now. Why duplicate effort?
People all over the place are discovering and enjoying Grails. It provides a solution now, everyone else is just talking about a solution.

Call me "opinionated", but one thing is for sure I said it at the end of last year and I'll say it again now. This is going to be one hell of a year for Groovy & Grails. So no Charles, you're not wrong, you are indeed right. Its just a matter of time and resources, and whether Sun are willing to to waste their time (Phobos) or commit to something special (Grails).

Grails Session accepted at JavaOne

2007-03-09T14:48:00.000Z

So here's some additional good news. As well as the Grails event at Sun Tech Days my session submission has passed Hani and the JavaOne panel's strict acceptance criteria and there will be a Grails session at JavaOne! See in San Francisco in May!

PS There may well be something else special Grails related happening at JavaOne, stay tuned.