This post is about my ambivalence about the Hibernate framework and its frequent partner, Spring. Proponents will tell you how it simplifies service layer calls to persist objects; allows a developer to think more completely in objects, and leads to a reduction in lines of code and inadvertent developer errors in persistence routines. The part of the equation that is often neglected is what it takes to design and configure a robust and usable Spring-Hibernate architecture.

These frameworks aren’t for the faint of heart – yes, if you’re walking into a gig where the architecture is already in place and the bugs are mostly ironed out; and, the team has bought or developed expertise in these frameworks, then using these frameworks is manageable and at times even easy. However, if you’re new to these frameworks and working on a project that has to ramp up quickly, design decisions can easily be made that make it challenging and time consuming to figure out how to do what you need to get done and how many configuration files you’ll need to do it.

Moreover, Hibernate now supports JPA annotations – which saves some time perhaps in that persistence strategies are visible in the entity model classes, however, learning the annotations is can be as challenging as learning how to set up the hbm.xml configurations. I’m not arguing that Hibernate isn’t powerful, on the contrary, I think there are lots features that allow inheritance or cascading across a class hierarchy to be succinctly expressed. The open question for me is whether or not the time and effort required to learn these features and their annotation syntax, limitations, edge cases, etc – really in the end results in a faster time to market or a more maintainable, flexible architecture.

This is a tough case to prove either way. My own experience over the last few months working with Spring and Hibernate is that once I learn something well, I feel like I’m saving time and effort. Unfortunately, since I have no parallel universe to experiment in, I’m hard pressed to say that writing the equivalent SQL and iterating a result set wouldn’t be faster for me to do an ultimately, more understandable when I have to maintain or enhance the code 6 months from now. I wasn’t around when the schema was developed but I think it is fair to say that a simple schema and transaction strategy can be implemented in a simple way using Spring and Hibernate, the problem is that real production applications rarely stay simple for long and as they morph to handle a broader and more varied problem domain, one’s expertise in Spring and Hibernate has to grow accordingly.

As heretical as it may seem to some, a viable alternative in my mind is to eschew these frameworks from the start and focus on gaining expertise in SQL; understanding the structure and performance quirks of your database implementation, and working with a UI toolkit (GWT or Vaadin) that doesn’t also impose the overhead of learning a bunch of arcane tags and strategies (JSF comes to mind). Of course, there are always new ways to do things in IT, I’m just leaning towards the possibility that simpler (even if it entails some redundant coding of JDBC calls or prepared statements, etc), would in the end be preferable. I’d rather rely on SQL than an abstraction layer that I can’t really change or optimize.

As I gain more experience and confidence with Spring and Hibernate, I can imagine my views changing somewhat but in the meantime, I keep asking myself, are all these layers and frameworks serving me, or me them?

When our son began gaming I was anxious about the security – bad people say bad things or leading our son astray. We avoided this with Runescape at the outset by refusing to enable chat. By the way, the only computer our son has access to is in the family room with no closed door to hide behind. So, we usually know when he is/was playing though we don’t stand behind him and watch everything he does – this would undermine any sense of trust we want to build in our relationship.

We really had no issues with Runescape, our son like to play a lot but eventually he got tired of it and the company’s filtering and our asking our son questions about the game, the chatting, and watching him play every so often to make our interest in him and his experience known, did the trick. Nothing untoward occurred and he graduated from Runescape to World of Warcraft (WOW).

WOW is a whole different beast and will get a separate post shortly.

I can’t say enough good things about Groovy – closures provide a simplified way to do so many standard things in code that if Groovy just supported closures and was like Java in every other respect it would still be a great advance for JVM compliant programming. Unlike Scala and Clojure, any Java program is a Groovy executable program just by converting the extension from .java to .groovy – it’s that easy. Of course, you’ll want to do some clean up on your code after that because Groovy provides automatic getter-setter generation, doesn’t need semicolons to terminate lines, and makes silly inconsistencies like the length versus size() methods go away (size() is used exclusively in Groovy though if you want to be confused, length is supported because it is still Java).

I’m going to cut this post short for now but plan to post more on Groovy topics, Maven integration with GMaven, TestNG usage with Hibernate, etc.