Using Groovy To Write Less Code

Spring example

by Rod Johnson,

• Re: Spring example

  by Paul King,

  • Re: Spring example

    by Rod Johnson,

Good article

by Rod Johnson,

Java 5.0

by John Davies,

• Re: Java 5.0

  by Rod Johnson,

very bad article

by Ahmet A. Akin,

• Re: very bad article

  by Ronald Miura,

  • Re: very bad article

    by Gerry Giese,

    • Re: very bad article

      by Rod Johnson,

  • Groovy code size benefits

    by Paul King,

• 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

  Like Reply

  Back to top

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

  Like Reply

  Back to top

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

  Like Reply

  Back to top

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

  Like Reply

  Back to top

• 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?

  Like Reply

  Back to top

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

  Like Reply

  Back to top

• 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?)

  Like Reply

  Back to top

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

  Like Reply

  Back to top

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

  Like Reply

  Back to top

• 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/

  Like Reply

  Back to top

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

  Like Reply

  Back to top