Why We Don’t Need Anonymous Inner Classes for Groovy/Grails

By Robert Fischer | Published: March 11, 2009

Most anonymous inner classes are really closures at heart, the same way inversion of control is really monadic handling at heart.

Groovy, recognizing this synchronicity, allows you to coerce a closure into an interface implementation via the as keyword. For instance:

// Groovy way of expressing the natural comparator
def c = {a,b -> a <=> b} as Comparator

Interfaces with multiple requirements can be implemented by constructing a map of string names to closure implementations, and then coercing the map via the as keyword.

So there’s really no need for anonymous inner classes. They’re theoretically coming in Groovy 1.7 in order to appease the Groovy-as-superset-of-Java sales pitch, but I wish Groovy would stick to its guns — the coercion is a lot nicer, and reveals what’s actually going on in the code: a function or two is being defined and passed around.

(Since it was noted that there’s no Google hook for this trick, I’ve decided to share it in the hopes that it will be picked up. “Anonymous inner class” or “inner class” for “Groovy” and “Grails” should really link to this stunt.)

Related posts:

  1. Useful Grails Integration Testing Snippet: Delete All Instances of Domain Classes
  2. Online Groovy and Grails Training
  3. My Groovy-on-Grails Experience
  4. Groovy and Grails Training Courses
  5. Last Call for “Intro to Groovy, Grails, and AJAX”!
This entry was posted in Programming Language Punditry. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.
  • http://jroller.com/aalmiray Andres Almiray

    Robert, I agree with you but there are some corner cases where anonymous inner classes are still desired, for example custom Swing cell renderers. As you may know you can use the coerce trick on Maps using abstract and concrete classes as well, not just interfaces; the problem comes that ‘super’ has no meaning in that context. Usually custom cell renderers delegate to their super class the construction of the base renderer component and then tweak it.

    Granted if your custom cell renderer code grows bigger than, say 10-15 lines, it should be place into its own top-level class, also if it should be visible by more than 1 component, therefore anon inner classes would not be needed.

    My $0.02

    • http://www.smokejumperit.com Robert Fischer

      @Andres

      If you’re looking for “super” — or really anything more than just adjusting a one-line interface, you should really do things in its own class. And anonymous inner classes consistently obscure things — for instance, when you say “super”, do you mean the inner class or outer class superclass? And the chattiness of inner classes is just horrid, and going to feel out-of-sync with the general expressiveness of Groovy.

  • Julius.GB

    Hi Robert,

    This is not related to what you’ve written, which is informative, but to how your posts arrived in Google Reader.

    Your posts started arriving at 20:18, London time, and for three hours, I’ve been receiving 2 posts every hour: 2 posts for 20:18, another 2 for 21:18, …, and 1 for 23:18. I waited to see if I would receive others at 00:18 but none came.

    I don’t know where the problem is: it could have been Google Reader or a one-off incident or how your set-up sends them out.

    If it was Google Reader, then I should have received my other subscribed posts in the same way: 2 posts every hour and 1 for the fourth hour. But it’s not the case, even considering the posts that arrived in the range of 2 to 10 minutes of receiving yours.

    Or maybe it was a one-off. In this case, I’ll wait till your other posts arrive.

    Or maybe your set-up needs a check up.

    • http://www.smokejumperit.com Robert Fischer

      @Julius.GB

      Is it the same 2 posts over and over again, or is it different posts?

  • Julius.GB

    Yes, it’s one post that I’ve received twice. At the end of the 4 hours, I had 7 copies of the one post.

  • http://www.smokejumperit.com Robert Fischer

    @Julius.GB

    But it’s stopped happening? If so, I’m writing it off as a Google Reader fluke.

  • http://simplefunctions.com simplefunctions

    Hey, thank you for posting this. It is very informative. To some end, a lot of the java users are not getting into grails because they are easier or less code to write. They are getting into it because of the industry. I got in because of the company i work for. So when grails is telling people, write java code and groovy will translate it and works fine. Obviously most of the convenience and convention of java programming still will get push onto grails and hopefully the framework will work as if it is a j2se or j2ee app. Unfortunately in the case of inner class, which is pretty common in java, is not implemented and closure which is an inner class but in grails’ world, along with its own syntax. Most people who does not know about it, wouldnt look twice. So googling inner class grails would not produce the result of what I was looking for. But it is nice to know a few more keywords to google next time i an up on a challenge again. And I’ll keep in mind of closure and how useful they are as like inner class to a java developer.

  • http://www.smokejumperit.com Robert Fischer

    @simplefunctions

    I’m writing an article for GroovyMag on the topic of functional programming in Groovy, probably for the May or June issue. It’s really going to be an exploration of Groovy Closures. You may want to keep an eye out for it.

    http://www.groovymag.com/

  • Pingback: David R. MacIver » Blog Archive » We don’t need anonymous inner classes? Bollocks to that.

  • http://jburich.blogspot.com Jason

    Although I do agree that the coercion is a much better way to write the code. Support for anonymous inner classes is also very high on the list of things I’d like to see in Groovy. I really don’t care to use them, however since Groovy is always presented as a superset of Java I think that it is very important to be able to take a .java file and rename it to .groovy and have it work. My current project was in need of some dynamic typing, and we choose Groovy as we figured it would be the best option to port straight from Java to Groovy. It wasn’t bad ( about 2 weeks work ) but there were a few things like anonymous inner classes that I was disappointed to see unsupported.

  • http://chrisbroadfoot.id.au Chris Broadfoot

    Here is a more thorough explanation for anyone that wants to replace anonymous inner classes that implement interfaces in Groovy:

    http://groovy.codehaus.org/Groovy+way+to+implement+interfaces

  • da

    how to override abstract classes with no default constructor in groovy without creating a new concrete class?

    • http://www.smokejumperit.com Robert Fischer

      @da

      You can’t. See the conversation above.

      The good news for you is that anonymous inner classes are supported in Groovy 1.7, which will be released any day now. :)

  • Categories