The Definitive Guide to Grails out in e-book form

After many months of hard graft, my book "The Definitive Guide to Grails" by Apress is available in e-form here. Thanks to all those that helped make it possible, and to those who do read it feel free send any feedback directly to me or post a comment. Cheers!

Why is Bruce Eckel arguing about typing?

In his article entitled "How to argue about typing", Bruce Eckel presents another argument against the downsides of Java's Strongly typed system. So let's analyze a few of the things he is most certainly right about:

• Checked Exceptions == Evil. No question.
• The fact that something like Eclipse generates code for you should not be an excuse for static typing. Code generation means duplication. In terms of DRY you are still repeating yourself whether it is generated or not. This makes code longer and harder to read.
• You shouldn't feel your system is more robust and "safer" because it uses static typing. This is a naive approach to development.

Ok, so that is the good stuff out the way. However, the problem I have with Bruce's article is that it again tries to turn the static vs. dynamic typing argument into, ummm.. an argument. Why are we arguing about this? In my view you should be picking the right tool for the job.

This is so fundamental. I mean both paradigms have their strengths and weaknesses, why does one rule out the other? Bruce's article implies the only benefit you get from static-typing is the knowledge that your application is checked at compile time for type safety, which represents a false sense of security anyway. Fundamentally, he says, all you're doing is testing, which you should have unit tests for anyway.

However, when I use Java I don't use it to feel "safe". I use it for the advanced code navigation, refactoring and analysis tools that you get in modern IDEs like Eclipse or IDEA. These tools are not just about generating code, they're about being able to easily maintain your codebase and allow it to scale in terms of complexity.

But, of course, Java is horribly verbose and is not suited to every task. In this sense I would say it is essential that every developer know both a dynamically typed and statically typed language so that you can use a blended approach to development. Getting the best of both worlds.

The thing is, in Agile one of the issues known to reduce productivity is task switching. If you are constantly switching between different programming environments that don't integrate seamlessly with each other you will become less productive. Fact. Also, if you can't easily integrate the two you will end up writing duplicate code for each platform, violating DRY.

This is the fundamental reason why I believe Groovy will be hugely successful. By integrating so tightly with Java and providing a seamless transition with the same APIs and object model it significantly reduces task switching and integration overhead.

My advice: Don't enter this debate. There is really nothing to argue about, choose the best tool for the job and use it. Sometimes that may be a statically typed language like Java, C# and so on other times it may be a dynamic language like Ruby, Groovy or Python. Choice is a good thing people.

Grails 0.3: Hibernate mapping has never been this easy

We've just put out Grails 0.3, which is a marked improvement over 0.2.2. Checkout this post for more info.

Possibly my favourite new feature of 0.3 is the improvements made to GORM, the ORM side of things that is built on Hibernate. It has become really concise. Defining persistent entities with relationships is as simple as:

class Author {
    static hasMany = [ books : Book ]

    String name
}
class Book {
    static belongsTo = Author

    Author author
    String title
}

Here we have a bidirectional one-to-many relationship. The 'hasMany' setting will inject a 'books' java.util.Set property into the class at compile time. Also injected are an 'id' property, and Hibernate's 'version' property to aid in transactions and optimistic locking.

GORM configures these classes as regular Hibernate persistent classes, but with a twist because Grails injects all sorts of helpful methods into them at runtime too. Such as those to manage relationships:

def a = new Author(name:"Stephen King")
             .addBook(new Book(title:"IT"))
             .addBook(new Book(title:"The Stand"))
             .save()

Here you create a new author instance, add two books to it and save it. In the background Grails is managing the relationships for you, making sure that both the one and the many side have references to each other and then through Hibernate persisting the instance with updates cascading to from the Author to each Book.

Notice how unobtrusive GORM is? No XML, no annotations clouding your domain model, just pure application logic that defines the relationships. And yet at the same time underneath it all it is still Hibernate, making it robust and enterprise ready.

This is of course only a small example, there are many more features of GORM such as all those dynamic finder and persistence methods. We have a lot more planned for 0.4, the next month is going to be fun. :-)