The adoption of JPA

I've been meaning to start introducing JPA for the persistence layer of our web applications for a long time, but there was never a "right time". That is, in our organization, every project is "an immediate need", needs to be delivered ASAP, and it always feels like we're in some kind of a "panic mode". So introducing the "new piece" of technology stack to our developers in the middle of projects with high deadline pressures did not feel feasible to me. Plus the relationship with our DBAs and the state of our databases (highly de-normalized "legacy" and even new tables, for the reasons unknown to me, etc.) kind of leaves bad taste in the mouth. But that's all internal corporate politics that I have no control over.

So, the last week a new such an immediate project came in and I decided to review it. It is a very simple CRUD application to maintain records of "emergency contact" for our students (and later for faculty/staff). It's a simple 1 web form backed by one de-normalized table. One of our developers assigned to this project started hacking (it is a typical Spring MVC app) with a Repository implemented as Spring JDBC (raw SQL - Oracle MERGE statement). It would be OK to leave it as it is, but I decided to "bite a bullet" and do the JPA implementation.

Thankfully, the JPA spec authors took care of the poor souls like us who have to deal with "legacy DB schemas" and equipped with @Embeddable, @AttributeOverride tools I was able to map this denormilized table structure into our simple model. This eliminated a lot of LOC of manual SQL craft code and manual mapping of result set into the JavaBeans. The solution turned out to be very elegant with only few lines of code! My colleague, who is the assigned developer on the project, really appreciated it.

Furthermore, with this JPA persistence model, we now could easily rewrite the front end in Grails and totally re-use it! That is my other plan - start introducing Grails to our organization, once 1.0 is out.

Later...