BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Using Groovy To Write Less Code

Using Groovy To Write Less Code

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

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

Community comments

  • Spring example

    by Rod Johnson,

  • Good article

    by Rod Johnson,

  • Java 5.0

    by John Davies,

  • very bad article

    by Ahmet A. Akin,

    • Spring example

      by Rod Johnson,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      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,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      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,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      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,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      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,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      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,

      Your message is awaiting moderation. Thank you for participating in the discussion.

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

      Your message is awaiting moderation. Thank you for participating in the discussion.

      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,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      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,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      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,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      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,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      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

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

BT