BT

Using Groovy To Write Less Code

| by Scott Delap Follow 0 Followers on Sep 21, 2006. Estimated reading time: less than one minute |
In a new IBM DeveloperWorks article, Scott Hickey compares writing code in Java versus Groovy. He finds that Groovy allows developers to focus more time writing algorithms and less time focusing on language semantics. In his first example a 60+ line JavaBean from Spring: A Developer's Notebook becomes a 24 line GroovyBean. An example focusing on testing shows how's Groovy's support for flexible constructors and setting object properties reduces code noise.  Many Java developers advocate writing unit tests in Groovy.  While organizations often have restrictions on production code, they don't have similar requirments on test cases.  The article also features examples in regards to polymorphism and Spring.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Spring example by Rod Johnson

The article contains an interesting example of how you can use Spring to configure and inject an object written in Groovy, with a regular bean definition.

In Spring 2.0 there is also a value-added integration with Groovy and other dynamic languages (including JRuby) that allows you to get additional functionality, such as having the container poll the Groovy source to pick up implementation changes in a threadsafe way, while honouring references injected into callers or obtained through getBean() calls.

An example from the Spring reference manual chapter on dynamic language support:


<lang:groovy id="fortune"
refresh-check-delay="3000"
script-source="/WEB-INF/groovy/FortuneController.groovy">
<lang:property name="fortuneService" ref="fortuneService"/>
</lang:groovy>


As of Spring 2.0, the Spring component model is essentially cross-language. So such components will benefit from out-of-the-box services such as declarative transaction management, and are eligible for advice by custom aspects using Spring AOP.

Rgds
Rod

Good article by Rod Johnson

Certainly, there are times when Groovy is very simple and concise. An interesting plus of Groovy is that it's very easy to start with for Java developers, as you can write Java-like Groovy until you become more comfortable with the additional syntax sugar and shortcuts.

I think it's encouraging to see greater recognition of the benefits of dynamic languages on the JVM.

Java 5.0 by John Davies

I'm not suggesting that Java 5 changes everything but there seems to be a lot of comparing numbers of lines and "noise". If the auther had used Java 5 features he would have seen a lot less noise not to mention lines of code from the Java versions.

-John-

Re: Java 5.0 by Rod Johnson

I'm not suggesting that Java 5 changes everything but there seems to be a lot of comparing numbers of lines and "noise". If the auther had used Java 5 features he would have seen a lot less noise not to mention lines of code from the Java versions.

True, Java 5 is a very much better experience than 1.4 and earlier. I now find it hard to stomach having the accept all those type casts when working on older code... And simple syntax sugar like the enhanced for loop makes a surprising different.

very bad article by Ahmet A. Akin

Java5 is out for two years now, why aouthor insists using Java 1.4? Grovy is a scripting language, it is expected to be less verbose. But author, posibly trying to prove his point, deliberately writes java code extremeley verbose. such as :

- the whole iterator code can be written in two lines with java 5
- You do not need to write blah.toString() if you want to write it to standat out.
- you dont need to put an extra empty constructor.
- if gorrvy properties are public, why java ones are private?

Re: very bad article by Ronald Miura

- if gorrvy properties are public, why java ones are private?

From the article:
The Groovy version is much, much smaller because Groovy's default property semantics automatically define a private field with public accessors and mutators. For example, the property model from above now has the equivalent of a getModel() and setModel() method automatically defined.

Re: very bad article by Gerry Giese

So all fields/attributes in Groovy are automatically private and automatically have get/set methods generated for them? All the get/set stuff is overblown if you ask me -- it's ok to have public fields if you *design* for it. But we're dug in so far that tool/library support almost requires get/set for every attribute of a class.

I noticed the Groovy toString() version left out weight and status. Also, the Java version had "this." sprinkled everywhere. I never use "this." if I can help it (do it like he did in the Groovy example - call the parameter "newXYZ".

Comparing productivity based on code size is only somewhat helpful. Groovy's benefit comes mainly from it's more dynamic nature. Certain syntactic elements are nice, too. Until lots of IDEs support it for highlighting, auto-complete, debugging, etc. then it's only useful for smaller stuff, but it definitely has potential. It will be interesting to see what happens with the new Scripting JSR and the languages Sun will support with it, such as their recent purchase (JRuby, right?)

Re: very bad article by Rod Johnson

But we're dug in so far that tool/library support almost requires get/set for every attribute of a class.

Well, JavaBean properties are certainly conveniently supported in IDEs: easy to generate, visualize etc. But good frameworks should not require the use of JavaBean properties. For example, with any good ORM framework, you can (and should) persist fields rather than properties, providing meaningful constructors to ensure testability. Similarly, with Spring and PicoContainer (and, I think, HiveMind) you can inject via constructors if you wish to use DI without property syntax. With Spring you can also construct via static or instance factory methods, which may have arguments. So framework/tool issues should not really dictate how to author a class.

The C# attribute syntax, while explicit, is a bit more rigorous than the Java form, which is merely a convention, not a language feature.

Groovy code size benefits by Paul King

I mostly gain code reductions using Groovy due to:

  • * no need for interfaces because of duck-typing

  • * compact builder syntax

  • * closures especially closures vs inner classes

  • * powerful language features such as built-in regex support

  • * powerful libraries such as SOAP, SQL, etc.

  • * built-in testing/mocking support

  • * GStrings

  • * Metaclass facilities to override getters/setters and more at a higher level and support DSLs

  • * named and optional method parameters

  • * more standard features not requiring imports



Just to name a few.

Getters/setters are a small win even over Java 5 but they are only minor. I am not sure they would make my top ten.

I write lots of Java and quite a bit of Groovy and the Groovy is usually a large percentage smaller if not several times smaller.

Re: Spring example by Paul King

For "Groovy in Action" I wrote similar examples for Spring 2.0. It includes examples illustrating:

  • * wiring Groovy beans with Spring

  • * dynamic compilation of Groovy scripts through the Groovy factory mechanism

  • * refreshable beans

  • * inline scripts within the configuration file



Chapter 11 contains these examples and is available in early access form at: www.manning.com/koenig/

Re: Spring example by Rod Johnson

Paul, thanks for the detail. I agree regarding your points where Groovy can be more concise: obviously properties are just a small part of the whole.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

11 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT