Grails: Interview on JavaPosse

There is a podcast interview with yours truely up on JavaPosse discussing my experiences with Groovy, what makes it so powerful and how Grails fits into the bigger picture of J2EE development.

Thanks to Dick and all the JavaPosse guys for taking their time out to chat to me, it was a most enjoyable experience.

PS I was a bit nervous in the beginning and I think it shows!

Grails: Ruby on Rails feeling the heat

Up until now I have not wanted to be drawn into a Grails vs Rails debate, clearly not wanting to start a flame war with the Ruby community, but it seems the Ruby/Rails people are doing that job perfectly well without my intervention and feel rather threatened by Grails as they keep bringing it up in interviews and comments on blogs.

In the latest podcast on the Ruby on Rails website they have an interview up with Tim Bray. They talk about Rails and the future of dynamic languages, and they brought up the topic of Grails in which the interviewer said and I quote:

"I heard that some guys had done a Groovy on Rails or Grails framework and didn't quite get it right."

Now, I encourage said interviewer to qualify his statement and point me to a reference where it says we havn't got it quite right. Clearly, you havn't tried Grails my dear boy and making such statements without the facts to back you up is really rather silly, and typical of the response from the Ruby community.

I follow all Grails news quite closely and not one user has said we havn't got it right in fact all the users on our mailing list that have taken up Grails feel we have got it very right with comments like Grails is "The Holy Grail" of Java web development and that its productivity is on par with Rails and for Java developers even more so because they can fully utilise their existing API knowledge.

So far there has yet to be a negative post about Grails from a Java developer, I'm sure there will be one, but I'm still waiting.. so the question is: are the Rails people feeling the heat?

The fact that they even mentioned Grails in this interview and have not mentioned any other Rails-like frameworks is a sign that they are worried and they should be. Grails takes Java integration to a new level. A level that will never be reached by the likes on JRuby on Rails, which really only serves as a useful proof-of-concept.

Good luck guys, Grails may have only just had a 0.1 release, but it has a growing following, greater integration with Java and an aggresive project plan and for the first time you have real competition.

Grails: The Render method and Ajax

Users of Ruby on Rails will be familiar with the 'render' method which allows rendering of responses from a controller. Grails has a similar mechanism, for example rendering text is as simple as:



render 'hello world!'
or
render(text:'world',contentType:'text/xml')

You can of course also render templates and views via the method (for more complete documentation see here), but what makes Grails' render method that little bit different is its support for markup building.

With other Java frameworks I've used I ended up with loads of partial views implemented as JSP or velocity views. Each with the sole responsibility of rendering some XML or JSON. With Grails this is rarely needed for pure XML responses (note, I would never condone defining layout in this way this is purely for data oriented XML rendering). Rendering XML is made infinitely more simple:



def results = Book.list()
render(contentType:'text/xml') {
books {
    for(b in results) {
        book(title:b.title)
    }
}
}

The above results in the following XML snippet being rendered to the response:



<books>
   <book title="The Shining" />
   <book title="Along came a Spider" />
</books>

When you combine this with how Grails controllers reload automatically on changing it makes writing ajax responses a breeze. But, there is more! Grails has inbuilt support for OpenRico so if you want to write Ajax responses in Ricos required format this can be done as follows:



render(builder:'rico') {
object(id:'bookUpdater') {
    books {
       for(b in results) {
          book(title:b.title)
       }
    }
}
}

Rico will then automatically look-up your 'bookUpdater' instance and delegate the response to it passing the contained XML to the updater for handling.

I don't normally like talking about unimplemented features, but thought it might be worthwhile just to highlight the power of the builder concept in Groovy as I don't believe that many grasp the potential of builders and their usages. One of the upcoming features in Grails is a JSON builder which will be available via the render method so say I wanted to render JSON instead of XML? We just change the content type defined in the render method:



render(contentType:'text/json') {
books {
    for(b in results) {
        book(title:b.title)
    }
}
}

And the resulting output would be JSON instead of the XML without any change to the structure of the builder code itself:



{
 books : [
     { title: 'The Shining' },
     { title: 'Along came a spider' }
 ]
}

Grails.org Live

Thanks to John Wilson of the Groovy development team who was on the ball enough to snap up the domain when it became available Grails has a new web home at www.grails.org!

Grails: Getting Started on Oracle 10g

Just got back from my easter break with the family and its great to see such fantastic tutorials being posted about Grails already including this one on how to get Grails up and running with Oracle 10g Express Edition.

Not only does it go through how to setup the database side of things, but it also talks you through deployment on OracleAS via a Grails WAR and improved deployment options. Great stuff.

Grails: Tag Libraries & The Power of Closures

When we started developing Grails we wanted to support a dynamic view technology that allowed scriptlets in Groovy instead of Java, but without falling into the trap of having scriptlets intermingled with HTML code a trap that many Java developers have spent years trying to avoid.

Historically though JSP custom tags have always been a bit of a pain to write, they're designed to cover every variation of tag under the sun, hence the API is complicated and the tag lib descriptors verbose. Grails is all about simplicity, so how do we avoid introducing this level of complexity into our Grails applications. The answer came in the form of anonymous code blocks or closures.

I would say 90% of the tags that are written for JSP out there fall into one of three categories: simple, logical or iterative. There are those more complex tags that have relationships to each other via nesting, but the vast majority are of the aforementioned type and Grails is about making the most common cases easy, but still allowing the flexibility to scale to the more complex (thats why we still support JSP).

So what have closures done to make custom tags easier? Well Grails allows you to define a custom tag as a JavaBean property. No descriptors, no configuration, and everything is reloaded at runtime so no need to restart that application server. So lets look at an example from the tag library that ships with Grails (simplified for clarity):



class ValidationTagLib {
     @Property eachError = { attrs, body ->
           def errors = attrs.bean.errors
           if(errors) {
               errors.each { body(it) }
           }
     }
}

Each tag library is simply a class that ends with the convention "TagLib". The above example contains an "eachError" tag that loops through each error contained within the "bean" attribute and invokes the "body" of the tag. Note how the body of the tag itself is a closure and hence callable, the attributes are a map. To use this tag we simple call it from our GSP no need to import the tag library or anything, the error itself is available using Groovy's implicit 'it' variable which was passed to the body closure:



   <g:eachError bean="${myBean}">
          <p style="color:red;">${it.defaultMessage}</p>
   </g:eachError >

Now thats pretty neat and simplistic, but this is where using closures for defining tags becomes really powerful. How about we want to re-use our "eachError" tag else where? Say we want to implement a default rendering tag called "renderErrors" that renders our errors as an HTML list. Well we can re-use the "eachErrors" tag to accomplish this:



@Property renderErrors = { attrs, body ->
   def markup = new groovy.xml.MarkupBuilder(out)
   markup.ul() {
      eachError(attrs) { err ->
          li( message(code:err.code) )
      }
   }
}

The above code creates a new MarkupBuilder instance which is used to generate an HTML list re-using the eachError tag defined previously, it actually uses a third Grails tag called "message" to retrieve the message for the error code. To call the "renderErrors" tag we simply do:



   <g:renderErrors bean="${myBean}"/>

Grails users can of course customise the inbuilt tags and add brand new ones simply by adding new tag library classes in the "grails-app/taglib" directory. So there you have it, custom tags have never been easier, and your markup can remain scriptlet free without the need to invest huge amounts of time creating a custom JSP tag library.

Grails 0.1 Released

Yes, that time has come, the first 0.1 release of Grails is out and I'm really pleased all or our hard toil has resulted in such a quality release. Grails has come a long way, I'm currently developing my first live project with it and it is a joy to use. There is still much to do though and we have some exciting features planned.

Over the coming weeks I will be posting on this blog about some of the features of Grails that I believe make it unique and not just another Rails clone. So stay tuned, the Grails journey has only just begun. :-)

Grails at JavaOne 2006

Well the session listings were posted a few days ago on the JavaOne 2006 conference website and if you browse into the Web Tier track you can see the details of the Grails session (BOF-2521) I will be presenting. Here's a quick link if you're lazy.

By that point Grails will (hopefully) have been released and a bit more interest garnered, but in the meantime checkout what will be covered.

Another interesting note is that there are 5 sessions (yes 5! There may even be more as I did my best to go through all the sessions but may have missed one) covering or related to the Groovy language. Making it the most covered dynamic language at the conference which is great news.

Also, don't forget to take in Guillaume's session on 'Simplifying Enterprise Development with Scripting' (TS-1246) and to those who are going to be there (Bob, you coming? ;-), see you there!

Groovy & BeanShell: Dynamic vs Scripting Languages

In my previous post I talked about the fundamental difference between Groovy and BeanShell and in one of the comments I was asked to elaborate on why exactly Groovy is dynamic and BeanShell is not. So here it, BeanShell is a scripting language, it is to Java what VBScript is to VB, the syntax is near identical, you can copy and paste Java code into BeanShell and vica versa. This makes it highly useful for doing things like testing Java code in isolation, or trying out a Java API through an interactive BeanShell console.

It is 'dynamic' in the sense that it uses reflection to achieve a lot of these goals, but beyond the aformentioned use cases I would not choose BeanShell over Java to implement say a build system, or a my web actions, or do text processing, advanced regex, output templates, as a view technology, this list can go on...

The reality is that BeanShell does not provide any productivity gain so to choose to use it for a task over Java (rather than use it to script Java) has no real benefit and this is because it does not have any of the true features of a dynamic language like Ruby or Groovy. I'm a big fan of WebWork and I've been using Groovy to write XWork actions because the advantages are clear, I can save/reload changes, I can use closures to manipulate and sort my data model:

projects.findAll { it.status == 'open' }.sort { it.name }

I can use GStrings, a concept known as string interpolation in languages like Perl and Ruby, and multi-line string support to easily manipulate strings:

def user = User.get(1)

def message = '''
Dear ${user.name},

Thank you for registering with xxx site,

Your password is: ${user.password}.

See you soon!
The Site
'''


There are many more examples of the kind of expressiveness mentioned above that Groovy allows in its syntax, but more importantly than all these syntatic niceties and what makes Groovy truely 'dynamic' is how methods (as well as constructors, properties etc.) are dispatched. Groovy has the concept of a MetaClass and it contains the methods that a class 'really' has as well those added dynamically at runtime, allowing new behaviours to be attached to new and existing classes. This is a feature Grails uses extensively to add behaviours to controllers, domain classes, tag libraries etc. all while still retaining the ability to use inheritence.

The reality is that Groovy and BeanShell are not really competing with each other at all, and address different problems entirely: BeanShell the scripting language for Java and Groovy the dynamic, agile language for the JVM. That is why I hope that instead of seeing articles like those written recently, we'll see some from the same people entitled "Using BeanShell to Prototype Java Code" or "Using Groovy to Power your Build System" as writing "Groovy is rubbish, and BeanShell is great" or vica versa is really not helping any newcomer who is interested in this space make an informed decision on which is the appropriate language for their use case.

Groovy: The Ed Burnette Effect

So as typically is the case when a few positive posts arise about Groovy, an alternative view point has cropped up entitled "BeanShell: groovier than Groovy" by Ed Burnette. The article quotes only the last paragraph of my previous post about how Groovy is approaching its "second" version 1.0, conveniently brushing over and failing to comment on any of the benefits highlighted.

Unfortunately, this is where many Java developers, with all due respect to Mr Burnette, fail to understand what a "dynamic" language is and its a shame this misunderstanding is being spread. I like BeanShell I appreciate what they are trying to do and in certain circumstances would recommend it over Groovy. It is great for embedding in Java applications if you want to script say an application server or or server component, but the fundamental difference is that BeanShell is a scripting language for the Java language, whilst Groovy is a "dynamic" language for the JVM (note the difference between Java the language and the JVM).

BeanShell is essentially Java without the need to specify types, which is great in certain circumstances, but doesn't really have much productivity gain and is not in my opinion the answer to the JVMs dynamic needs. I have written a lot of code in both BeanShell and Groovy and with Groovy my lines of code (LOC) count is about 60-70% less then the equivalent Java code, with BeanShell this is about 10%, as its essentially just Java without the need for type safety.

This is also why BeanShell has managed to achieve relative stability and a small size (as highlighted in Ed's article) when compared to Groovy as its goals are relatively simple. Groovy adds new language constructs, closures, the GDK methods, builders, meta-programming etc. This is not something you can achieve without spending a longer period of time defining the language and the API. Yes, following the standardisation process there was a re-think of many of the aspects, but this is the usual process with the JSR and any standard spec. Fortunately the syntax, through this process, has been nailed down and the Groovy development team are merely focusing on improving the core of Groovy.

Groovy: The Sleeping Giant, an Elaboration

Richard Monson-Haefel recently wrote an interesting blog post about
Groovy, titled "Groovy: the sleeping giant". The post talks about the dynamic future, which is certainly coming with the increase in popularity of agile methodologies and Ajax in particular spurring it on, and talks about how Groovy could be the solution the Java platform needs. The interesting thing for me though, is although I agree with many of the points I do disagree with some.

Firstly, I believe in a blend, its not going to be dynamic everything. The fact remains there are still huge benefits to compiled languages such as Java especially in large systems where the benefit of refactoring and powerful IDEs becomes clear. But, it is there where Groovy's true strength lies in its ability to cleanly interface with Java. In addition there are other, largely undocumented, reasons why Groovy has huge amounts of potential:

• Meta-programming - Groovy has the ability to inject methods, constructors, properties, fields, etc. into ANY java class at runtime. Most of what AOP is used for nowadays can be achieved with Groovy's Meta-programming capability. No byte-code manipulation a la AspectJ, this is awesomely powerful and in combination with Groovy's support for closures and builders it makes it possibly to create mini-DSLs
• Power Features - Although there has been a lot of argument about the optional parenthesis, and the optional semi-colons etc. There are very good reasons for these things being optional: For combining closures and method calls to allow builder syntax. Builders and closures are very powerful, especially when you consider you can pass the same closure to a multiple different builders. Why you say? Well one may output a tree structure as XML another might render a GUI from it, I'll leave the rest to your imagination.
• True Object Orientation - Everything is an object in Groovy, you may think this is strange given Java has primitive types, but all the auto boxing and unboxing happens at runtime, no Java 5.0 required. This means you can have methods on numbers, overload operators by adding a specifically named method call, use advanced switch statements that don't just work with char and int.
• Grails - Ok I'm biased on this one, but I believe Grails has huge potential to succeed in areas where Rails has unfortunately been unable to penetrate. On those thousands of companies that have invested huge amounts of money in Java and are not about to dump that $35k per CPU application server. For those who have legacy database systems that need to be mapped onto, existing Java services that need to be interfaced with seamlessly and team of developers all skilled in, you guessed it, Java.

So there you have it, Groovy has had its problems, and the FUD that has been spread hasn't helped. But, Groovy is still young, 10 years younger than Ruby in fact, and a fantastic amount has been achieved for it to be where it is today. I look forward to the upcoming release of Groovy 1.0.

Grails CVS Moved

As Grails is growing up it has moved to its own home, out of the modules directory with Groovy, into its own CVS repository

For info on how to get the latest code take a look at these instructions

New Grails Website Live

The new grails website is up and running at http://grails.codehaus.org. The design of this one is better thought out, easier to navigate and overall a great improvement.

The site should now be less of an embarrassment when the first Grails release attracts (hopefully) a few visitors.

Well this is my first post at my new blogging home, I will be posting here as often as I can about various things mostly around web development, and in particular with Grails (http://grails.codehaus.org) which is my current project.

Stay tuned for more as Grails is approaching its first release which should be interesting :-)