At JavaOne there was a session that is now online comparing Rails, Grails and J2EE. They say some good stuff about all three, but one can’t help but feel - unsurprisingly perhaps - that J2EE comes out smelling of roses rather unfairly.

I hope that the presenters, Damien Cooke and Tom Daly of Sun Microsystems, Inc. can get in touch with the Grails team to confirm how they ran these tests that supposedly show Grails using a huge amount of CPU compared to Rails and J2EE.

After all, we have run benchmarks that seem to be fair against Rails, and Grails throughput is much better in almost all cases. So at a basic level this cannot support the high Grails CPU usage vs Rails.

This makes me think they ran grails with “grails run-app” which runs grails in Jetty with loads of extra code to support dynamic reloading and compilation in development mode. If they did this, they should have executed “grails war” (which they know about, says it elsewhere) and run it in Tomcat/Glassfish to compare with J2EE.

There are so many typos in the document you can’t help but wonder about the quality of work involved. They call Groovy a “JavaScript” programming language. They show Grails with source code examples inline making things look complicated, and then show 4 simple bullet points for creating a CRUD J2EE application (in what universe is this?).

They say that one of the “problems” with Grails is that its made up of lots of other bits of tech - Hibernate, Spring, SiteMesh etc. Of course they would say this, but they are in denial that these are actually the best of breed APIs out there as opposed to the awful EJB, JSP, JSF gumph. They also say you have to configure all this stuff. Hmm, I think they haven’t tried convention over configuration at all.

Then there are things like “Not clear how to regenerate if you have made changes to the controller/views”. There’s nothing to do! Reload!

Pah, oh well. Damien and Tom, if you want to get in touch and give us precise details of how you did your Grails testing we’d like to help check it was a fair comparison

– The Anyware Blog

Tags: Grails

– Hansamann

Tags: Audio, Grails

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

– Graeme Rocher

Tags: Graeme Rocher, Grails

For this week’s print issue, we did a big story on the Java-based scripting languages. Over the past few years, Web application developers have been gravitating towards scripting languages such as Ruby on Rails and PHP, which allow them to quickly ramp-up applications.

The received wisdom around these languages, and the frameworks they operate under, is that they can not match the performance of an application running off of Java Enterprise Edition, which, after, was built expressly for multi-thread environments. (And this is why the scripting languages like Groovy that can run on the Java Virtual Machine are such good news: They combine the speed of the Java platform with the ease of the scripting languages).

In any case, it turns out that this perception about scripting-based applications running slower is correct—at least according to tests carried out by Sun engineers.

Sun Microsystems senior performance engineer Tom Daly and Sun engineer Damien Cooke recently compared the performance of Ruby on Rails and Grails (a rapid development environment for Groovy) against a typical Java Enterprise Edition-based deployment. They discussed their findings at the recent JavaOne conference, held in San Francisco last month.

They found that Ruby on Rails could not match the performance of JEE 5, nor could Grails, though it fared slightly better. They did concede that both Ruby and Grails were easier to work with though.

For the tests, the duo built three identical applications, a software support registration system called RegPerf. One version was written in Ruby on Rails, one in Grails and one using Java EE 5. This Web application, tied to a PostGres database, allowed users to create, update and delete data. They two engineers installed their software on a Sun Solaris server with four Advanced Micro Devices Opteron CPU’s and 8GB of memory. To simulate a whole bunch of users interacting with the software, they used Faban, a Sun open source load-testing generation tool.

Here’s how the platforms fared: The Ruby on Rails deployment was able to execute about 2,000 operations per second (such as reading a database entry, or refreshing the Web page), whilst serving 100 users simultaneously. Grails executed just over 3,250 operations per second for 100 users. And JEE 5 trumped both of the others, executing almost 11,000 operations per second with 100 users.

As the load grew to 500 users, the performance of all three slipped, as expected. When 500 simulated users hit the Ruby on Rails system, the server was only able to execute a little over 1,250 operations per second. Grails shrank to something over 2,500 users and JEE5 slipped to about 5,500 operations per second. (Note: the numbers are wrong in the presentation materials on the JavaOne site).

The Java EE deployment also seemed to utilize the processors less than either Ruby on Rails or Grails.

While these tests showed JEE 5 seems to be the fastest performer, Daly did show that setting up an application in JEE 5 takes considerably more work than in does with either Ruby on Rails or Grails. It still may make sense to use Ruby on Rails or Grails to set something up quickly, though if you expect your Web application to be used heavily, it might be better to spend the additional time to deploy the application in Java EE, he said.

“Frameworks are great for doing quick integration stuff, for getting going very quickly. But will they scale up? What is the maintainability like? Those are the questions to ask,” Daly said.

Daly stressed that the tests were not proper benchmarks, because each of the configurations ran without tuning. Rather the team did this exercise in order to show how users could set up their own tests when thinking about which framework to deploy.

– Joab Jackson, Government Computer News Tech Blog

Tags: Grails

This episode gives you a background on Groovy Typing, e.g. optional Typing, etc.

— Hansamann

Tags: Audio, Grails

Thinwire, which is an open source Ajax framework, was one of the more interesting technologies that I encountered at JavaOne. It provides a Swing-like API for building a web GUI. Your application code, which runs in the web container, constructs a GUI component hierarchy, which is then rendered by an Ajax client in the browser. See the website for an example. Last year, I helped develop the server-side part of a similar framework along with a demo application. I found it to be an extremely compelling way of building a web application: nice server-side Java code with no messy HTML or JavaScript. It’s great to see that Thinwire are offering something similar.

In order to see whether Thinwire lives up to it’s promise I decided to build a Thinwire front-end to Project Track , which is a sample JSF, Spring, Hibernate and Acegi application developed by myself and Kito Mann. To make it a little more interesting I decided to use Groovy as the implementation language.

A major part of using Thinwire consist of building hierarchies of GUI components using code like this

  Dialog dialog= new Dialog(..)

  Button button = new Button(...)

  dialog.getChildren().add(button)

One of the neat things about Groovy is that has the concept of builders, which can simplify this kind of code. Here is what I came up with:

 class ThinwireBuilder extends BuilderSupport {

    def components = new ComponentContainer()

    public Object createNode(Object name, Map attributes) {
        def component = attributes.type.newInstance(attributes.label)
        components.put(name, component)
        if (attributes.bounds) {
            component.setBounds(*attributes)
        }
        if (attributes.click) {
            component.addActionListener("click", new MyActionListener(attributes.click));
            attributes.click.delegate = components
        }
        return component

    }

    public void setParent(parent, child) {
        parent.getChildren().add(child);
    }

....

}

The createNode() method instantiates a component using the attributes passed in as a Map (attributes.x is shorthand for attributes.get(”x”)). The builder also lets the click listener for a button be a Groovy closure, which eliminates the clutter of anonymous inner classes. The builder maintains a map of names to components using the components property, which is an instance of this class:

class ComponentContainer {

    def components

    ComponentContainer() {
        this.components = new HashMap()
    }

    public Object getProperty(String name) {
        return components.get(name)
    }

    public Object get(name) {
        return components.get(name)
    }

    public void put(name,value) {
        components.put(name, value)
    }

}

With this builder in place I was then able to rewrite Thinwire’s Hello World example like this:

public class Main {
    public static void main(String[] args) {

        def builder = new ThinwireBuilder()

        builder.dialog(type: Dialog, label: "Hello World, ThinWire Style!", bounds: [25, 25, 215, 120])  {
            label(type: Label, label: "Hello, what is your name?", bounds: [5, 5, 200, 25])
            input(type: TextField, bounds: [5, 35, 200, 25])
            button(type: Button, label: "Ok", bounds: [55, 65, 100, 25 ], click: {
               MessageBox.confirm("Hello " + input.getText() + "!");
               dialog.setVisible(false)
            } )
        }

        def dialog = builder.components.dialog
        dialog.setVisible(true);
    } 

}

Note that the closure that handles the click event references the input and dialog properties even though they have not been explicitly defined. That’s accomplished in the builder by setting the closure’s delegate to components. Quite slick!

The Main program is then specified as an init-param of the Thinwire Servlet:

  <servlet>
    <servlet-name>thinwire</servlet-name>
    <servlet-class>thinwire.render.web.WebServlet</servlet-class>

    <init-param>
      <param-name>mainClass</param-name>
      <param-value>net.chrisrichardson.thinwire-example.Main</param-value>
    </init-param>

  <//servlet>

I also had to add groovy support to the maven project, which is accomplished by using the maven groovy plugin:

            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>groovy-maven-plugin</artifactId>
                <executions>
                    <execution>
                        <goals>
                            <goal>compile</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

With that in place I could then type ‘mvn clean package cargo:start’ to run my Thinwire web application. This is what it looks like in the browser:

Next time, I’ll write about the Thinwire front-end for Project Track

– Chris Richardson

Tags: Groovy

There’s been a lot of people asking for a Java loop syntax in groovy. A lot if not almost all usages however are cleaner without it, once you know some idiomatic groovy.

Here are just some of the examples of looping constructs available in groovy:

def results = []
10.times { results << it }
assert results == [0,1,2,3,4,5,6,7,8,9]

results = []
0.step(10, 2) { results << it }
assert results == [0,2,4,6,8]

results = []
(1..10).each { results << it }
assert results == [1,2,3,4,5,6,7,8,9,10]

results = []
(1..10).step(2) { results << it }
assert results == [1,3,5,7,9]

def items = [‘one’, ‘two’, ‘three’, ‘four’]
results = []
items.eachWithIndex { item, idx ->
results << idx
}
assert results == [0,1,2,3]

There are a whole range of Groovy features at work here, from inline lists to ranges, GDK methods added to JDK classes such as step() on numeric types and of course closures.

– Mark Palmer

Tags: Groovy

Ok so a number of folks have written comments and emailed me privately based on my post, nay rant regarding J2EE [LINK]. I think some further clarification is warranted lest you get the wrong impression. And no I’m not back-peddling.

My stance is that J2EE as a web-development platform (presentation, middle-tier, database) is bloated. For prototyping, rapid development, agile methodologies you’re better off in my opinion going with something like ASP.NET, Ruby on Rails or Groovy on Grails (I wish they’d named this stuff better, it feels ridiculous to even type the words).

Here’s some of what I would call legitimate gripes:

1. Everyone knows the mess that EJBs are/were. Not to say that J2EE is all about EJBs but if you lived through it, EJBs wasted everyone’s time and energy. As an aside, I am a certified IBM EJB developer.
2. Java tools are ridiculously expensive. Yes Eclipse is free but everyone builds on eclipse and you end up paying third party vendors to flesh out your IDE.
3. Write once deploy anywhere - Doesn’t work so why bother.
4. Getting a stack that works. Granted you can easily put together a greenfield stack of tech that works, as Jordan pointed out in my last post [LINK]. But getting more than one technology to work together in the J2EE environment is tricky. E.g. Websphere Application server and say JBoss. Usually what I have found is all is fine until you start introducing stuff into the mix. You need such and such version of WAS with such and such version of Product XXX. I’ve even seen people setup entire containers and make RMI calls just to string products together. Big mess.
5. Vendor lock in. Sort of a follow on to 4 but once you start writing java that uses the extensions a particular vendor has made you’re locked in.
6. General productivity vs .NET: I just think the IDE of studio is streets ahead of the Java IDEs out there. That’s probably personal preference. I’ve also seen markedly higher productivity from development staff when using .NET vs Java.

I’d like to think I’m impartial and go where the best technology is. On the server I’d maintain Java is the platform to beat. The throughput, security, reliability are all there. .Net has made huge gains in this department and will continue to do so. If I were setting up a company from scratch I would probably pick a .NET stack top to bottom given where .NET is at today. In reality though most places have java on the server and have built software policies around ensuring only J2EE is there, where it belongs so you can’t fight reality.

Certainly .NET has it’s faults. It’s not free, Studio does cost $$$. I think ideas tend to trickle down from the Java world to .NET so there’s a certain amount of “borrowing” that goes on.
You get vendor lock in as well as platform lock in for the most part. I don’t really mind these things though as these are at least openly admitted up front.

As for Groovy and Ruby, I’m still a newbie on these things but they look interesting compared to J2EE development. Unfortunately I think they’re not at the level of ASP.NET yet as far as developer support. I really hope they get there though.

– Francis Shanahan

Tags: Grails

From Grails.org: The Grails development team has reached another milestone and is pleased to announce the release of version 0.5.5 of the Grails web-application development framework.

Grails is a dynamic web-application framework built in Java and Groovy, leveraging best of breed APIs from the J2EE sphere including Spring, Hibernate and SiteMesh. Grails brings to Java and Groovy developers the joys of convention-based rapid development while allowing them to leverage their existing knowledge and capitalize on the proven and performant APIs Java developers have been using for years.

Thank you to all the team members, patch contributors and users. A lot of hard work has gone into this release - we hope you enjoy using this latest installment of the Grails adventure.

New Features

• New Plug-in Distribution Mechanism
• New Plug-in auto-discovery and installation
• ExpandoMetaClass improvements to add methods onto interfaces (http://groovy.codehaus.org/ExpandoMetaClass)
• Re-worked Unit testing to support separate unit and integration testing
• Dependency Injection for domain classes
• Support for organising projects with standard Java/Groovy packaging

New Plug-in Distribution Mechanism

Plugin authors can now distribute their plugins simply by typing:

grails release-plugin

New Plug-in auto-discovery and installation

Typing

grails list-plugins

Produces a comprehensive list of what is current released in the Grails plug-in SVN which can be auto-installed on demand:

Plug-ins available in the Grails repository are listed below:
-------------------------------------------------------------
...
quartz              <0.1>               --      This plugin adds Quartz job scheduling features to Grails application.
radeox              <0.1>               --      A plugin for the Radeox Wiki-render engine to allow easy markup and cross-linking.
remoting            <0.2>               —      Adds easy-to-use server-side and client-side RPC support.
scaffoldtags        <no releases>       —      No description available
searchable          <0.3 (?)>           —      This is a zip release, no info available for it
staticresources     <no releases>       —      No description available
wicket              <0.3>               —      Provides integration between Grails and the Wicket framework
xfire               <no releases>       —      No description available
…
To find more info about plugin type ‘grails plugin-info [NAME]’

To install type ‘grails install-plugin [NAME] [VERSION]’

For further info visit http://grails.org/Plugins

ExpandoMetaClass improvements to add methods onto interfaces

See Groovy docs for info (http://groovy.codehaus.org/ExpandoMetaClass)

Re-worked Unit testing to support separate unit and integration testing

Tests are now split into fast running unit tests and integration tests that load the whole environment:

Individual tests can be run with grails test-app TEST_NAME. Full reports are output to test/reports:

Dependency Injection for domain classes

The default constructors for domain classes has been overriden to retrieve prototype beans from the application contex which can take advantage of auto-wiring.

new Book() // dependent beans auto-wired automatically with new operator!

Tags: Grails

Thinwire, which is an open source Ajax framework, was one of the more interesting technologies that I encountered at JavaOne. It provides a Swing-like API for building a web GUI. Your application code, which runs in the web container, constructs a GUI component hierarchy, which is then rendered by an Ajax client in the browser. See the website for an example. Last year, I helped develop the server-side part of a similar framework along with a demo application. I found it to be an extremely compelling way of building a web application: nice server-side Java code with no messy HTML or JavaScript. It’s great to see that Thinwire are offering something similar.

In order to see whether Thinwire lives up to it’s promise I decided to build a Thinwire front-end to Project Track , which is a sample JSF, Spring, Hibernate and Acegi application developed by myself and Kito Mann. To make it a little more interesting I decided to use Groovy as the implementation language.

A major part of using Thinwire consist of building hierarchies of GUI components using code like this

  Dialog dialog= new Dialog(..)

  Button button = new Button(...)

  dialog.getChildren().add(button)

One of the neat things about Groovy is that has the concept of builders, which can simplify this kind of code. Here is what I came up with:

 class ThinwireBuilder extends BuilderSupport {

    def components = new ComponentContainer()

    public Object createNode(Object name, Map attributes) {
        def component = attributes.type.newInstance(attributes.label)
        components.put(name, component)
        if (attributes.bounds) {
            component.setBounds(*attributes)
        }
        if (attributes.click) {
            component.addActionListener("click", new MyActionListener(attributes.click));
            attributes.click.delegate = components
        }
        return component

    }

    public void setParent(parent, child) {
        parent.getChildren().add(child);
    }

....

}

The createNode() method instantiates a component using the attributes passed in as a Map (attributes.x is shorthand for attributes.get(”x”)). The builder also lets the click listener for a button be a Groovy closure, which eliminates the clutter of anonymous inner classes. The builder maintains a map of names to components using the components property, which is an instance of this class:

class ComponentContainer {

    def components

    ComponentContainer() {
        this.components = new HashMap()
    }

    public Object getProperty(String name) {
        return components.get(name)
    }

    public Object get(name) {
        return components.get(name)
    }

    public void put(name,value) {
        components.put(name, value)
    }

}

With this builder in place I was then able to rewrite Thinwire’s Hello World example like this:

public class Main {
    public static void main(String[] args) {

        def builder = new ThinwireBuilder()

        builder.dialog(type: Dialog, label: "Hello World, ThinWire Style!", bounds: [25, 25, 215, 120])  {
            label(type: Label, label: "Hello, what is your name?", bounds: [5, 5, 200, 25])
            input(type: TextField, bounds: [5, 35, 200, 25])
            button(type: Button, label: "Ok", bounds: [55, 65, 100, 25 ], click: {
               MessageBox.confirm("Hello " + input.getText() + "!");
               dialog.setVisible(false)
            } )
        }

        def dialog = builder.components.dialog
        dialog.setVisible(true);
    } 

}

Note that the closure that handles the click event references the input and dialog properties even though they have not been explicitly defined. That’s accomplished in the builder by setting the closure’s delegate to components. Quite slick!

The Main program is then specified as an init-param of the Thinwire Servlet:

  <servlet>
    <servlet-name>thinwire</servlet-name>
    <servlet-class>thinwire.render.web.WebServlet</servlet-class>

    <init-param>
      <param-name>mainClass</param-name>
      <param-value>net.chrisrichardson.thinwire-example.Main</param-value>
    </init-param>

  <//servlet>

I also had to add groovy support to the maven project, which is accomplished by using the maven groovy plugin:

            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>groovy-maven-plugin</artifactId>
                <executions>
                    <execution>
                        <goals>
                            <goal>compile</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

With that in place I could then type ‘mvn clean package cargo:start’ to run my Thinwire web application. This is what it looks like in the browser:

Next time, I’ll write about the Thinwire front-end for Project Track

– Chris Richardson

Tags: Groovy