Skip to content

links for 2011-02-23

links for 2011-02-12

Groovy Goodness – Getting Rid of ‘getX’

There’s so many productivity boosts that Groovy offers that it is hard to pick a favorite. One big gain from Groovy is simply that I have to type less to get the job done; meaningless conventions that I’d grown accustomed to creating just aren’t required. In particular, not having to write getters and setters for instance variables and being able to reference them and methods using dot notation is a big win. In the following example below, if I have a handle to a user and want to access the user’s name or set the user’s name, isn’t the following crystal clear without get/set and parentheses?
User user = serviceMethod.getMyUserById('12345')
println user.name
//update user's name
user.name = 'GroovyGuy'

What more is needed to make what’s going on clear to another programmer?

Jump Hibernate Transaction Boundary with Groovy Closure

This isn’t my original idea, a colleague was pair programming with me but I was at the keyboard when the idea came to his mind – so I claim some small credit for finger effort ;-)

The problem we encountered in Hibernate is that loading a lazily initialized collection in a transactional method was sometimes problem because the session would be closed after getting the parent object. We’ve been looking for a slick way to side-step the transaction boundaries and Groovy’s closure mechanism seems like as good approach. Here’s what we did – dead simple.

@Transactional(... rest of Hibernate standard annotation parameters)
def void withTransaction(Closure cl) {
cl.call()
}

That’s it! When the method is called, the Closure argument is inside the transaction and you can invoke the loading of lazy initialized child collections without a problem.

To end with a bang, an even slicker approach is the following code though we’ve found both the previous method and the following one are useful in different situations.
@Transactional(... rest of Hibernate standard annotation parameters)
public Object withEntity(Class objectClass, Serializable id, Closure cl) {
hibernateGet(objectClass, id)?.with { cl.call(it) }
}

For the less closure minded let me break this down. Hibernate ‘gets’ require the class name of the object and the id (String implements Serializable) – the closure is passed to do the heavy lifting. hibernateGet obtains the object and the ‘?’ is Groovy’s native null check operator (if the object is null the method returns null rather than a NullPointerException – another slick bit of Groovy functionality compared to Java) – the ‘with’ is another standard Groovy closure mechanism somewhat akin to the Microsoft VBA with that uses the object and then accepts the passed Closure cl. cl.call is the invocation of the Closure and the ‘it’ is the object that is the initiator/invoker of the closure. So the object returned from Hibernate’s ‘get’ is evaluated by with using the Closure ‘cl’ to operate on the object. Since it’s all in one transaction there isn’t an issue with initializing a lazily loaded child object of the returned parent.

Groovy in my mind is Java as it should be. Any Java file compiles (in truth there are few small gotchas but that’s for another post) as a Grooy file just by changing the file extension to .groovy. The syntax enhancements, simplifications, and improvements are huge boosts to my productivity. If you haven’t experimented with Groovy I encourage you to try it out.

Science and Meditation Update

A recent New York Times article cites research that has identified physical changes to the brain as a result of meditation practice.

http://well.blogs.nytimes.com/2011/01/28/how-meditation-may-change-the-brain/?ref=health

links for 2011-01-16

links for 2011-01-11

Review of SpringSource SpringOne 2GX Conference

I was surprised with an invite from my company to attend the SpringSource conference in Lombard this week. We’re heavily dependent on Spring and the the 2GX part was about Groovy (which we use and love) and Grails (which I’d love to use). This was my first industry conference and I had a notion about how a successful open source company like Spring Source would run such a show.

I really enjoyed the Groovy offerings and will write more about them later in this post but I was completely unprepared for the commercial side of the conference. It makes sense that there are sponsors (VMWare owns SpringSource and I found out that EMCO owns VMWare) so there are big players involved in the conference. While I’m not naive about such practicalities I have to say I was creeped out by Rod Johnson’s (Spring’s creator) keynote address. It was one shameless commercial plug after another – it reminded me of meetings I’ve sat in with IBM reps.

The keynote the following night was a bit better and focused on some concrete forward looking aspects of Spring and related technologies without so many obvious pitches. Though we use VMWare heavily, I didn’t go to a single VMWare presentation so the keynotes were the extent of my being marketed to for the conference.

The Groovy topical material was generally very high quality. The teaching was somewhat variable but the presenters were all quite expert on their respective Groovy topics. Guillaume LaForge, the project lead for Groovy is a nice guy and gave a solid presentation on the Gaelyk framework for the Google App Engine. I learned a great deal about the App Engine and why I might like to build something to run on it under certain circumstances.

I went to a couple of Groovy GORM talks where there were some good take aways on db performance and optimization when using Hibernate with GORM. Also, it was announced that GORM will now support NoSQL persistence and of course, VMWare offers such a product. There were a couple of great sessions on Meta Programming and AST transformation. Groovy offers such powerful dynamic coding that I could see a downside being that these sorts of solutions are sought out too often.

There were a couple of lack-luster talks that crammed too much information in too short a time and turned into fast survey courses that I could have done just as well with Google. Concurrency was one of the topics that was treated this way and also one of the DSL presentations was a bit too introductory, time ran short and then the good stuff was rushed through at the end.

By far, the most practical talks were the one on functional programming styles available in Groovy and 3 talks on Gradle. I understand recursion but I guess I slept through the important point that tail-recursion has to be supported by the language itself – just making your recursive call at the tail end of a recursive function won’t protect you from stack overflows (bummer). I learned that the real win of tail recursion is that a tail recursive function is converted to iteration at compile time to avoid stack overflows. OK – I know some of you are thinking that I’m a dork for programming all these years and not knowing this but I haven’t ever had to write a large recursive routine. So, please forgive my ignorance and keep reading my blog :-)

The Gradle tool looks awesome. The creator of it Hans Dokter, I believe, spoke on the evolution of build systems as a design domain which was interesting. Oddly, he never mentioned Make and just started with Ant but I suppose that is a Java-ism that is reasonable since Ant seems like a reinvention of Make using XML. Anyhow, Gradle is a very smart and flexible toolkit; not a framework. It is written in Java but scriptable using Groovy. There is a tight integration to Ant tasks and the Gradle folks are working to improve Maven integration/migration capabilities as they move towards a 1.0 release.

Overall, I enjoyed the conference and thought it was worth my time and would go back next year if I can make it.

links for 2010-10-15

Java to Groovy – little not so groovy gotcha

We found out the hard way today that Java code ported to Groovy simply by changing the file extension will be valid Java code but it won’t always work exactly as before. The culprit was a double-quoted concatenated multi-line string that had a leading plus on one or more of the lines. In Java, with line endings delimited by the semi-colon character I suppose this wasn’t an issue but an oddly constructed string made Groovy thing that the plus sign was something other than the overloaded concatenation operator that it was in Java.


// Bad - won't do the concatenation
System.out.println("hey, this is line one"
+ " the starting plus sign is no longer viewed as a"
+ " concatenation if this is in a Groovy file")

// Use this instead or better still a Groovy println call.
System.out.println("hey, this is line one" +
" the starting plus sign is no longer viewed as a" +
" concatenation if this is in a Groovy file")

Eclipse isn’t much help seeing this error and I didn’t get a chance to look at it in Intellij to see if it is more helpful. The way it was caught was that the debugger wouldn’t stop on the line properly and when the badly concatenated exception message variable value was read it was truncated. We were chasing down some other problems at the time so this anomalous debugger behavior was on the list of things to investigate but it turned out to be the root cause of the errors we were seeing because this construct appeared in several files.