JavaScript Loaders

Friday, January 11, 2008

Java Persistence API (JPA) Acceptance

JPA is arguably one of the best Java enterprise technologies introduced in last several years. The evolution of entity EJBs is hardly a happy path for other technologies to follow. But fact of the matter is it resulted in JPA which at least partially redeems its previous failures and half-failures. Of course, Gavin King should be credited, at least partially, as a savior for the J2EE persistence technology for its widely accepted Hibernate. But Sun had guts to discard its own ideas and re-position EJB3 and JPA as best of breed industry standard.

At the same time hardly anyone will argue that JPA acceptance is not where it should be for such advanced technology. There are couple of reasons for this:

1. JPA presents a large shift for EJB persistence. Both programmers who used entity beans before and programmers who discarded entity beans as not practical and sticked to JDBC-based APIs do not jump on JPA for the same reason: it presents a steep learning curve (sorry for mathematical nonsense) for both camps.

2. JPA is largely based on ORM technologies such as Hibernate which have very strong following of its own. It would be hard to convince a Hibernate developer to switch to JPA just because it's a new standard. Hibernate 3 is more flexible and feature rich. After all, with introduction of JPA Hibernate takes place of legacy code and legacy code as we all know is here to stay.

Thus, adoption of JPA is probably slower than it deserves but it should not scare away people who are evaluating it for new projects or consider upgrading now legacy ORM implementations. JPA will eventually take place of JDBC and ORM technologies by making JDBC stack as invisible tomorrow as TCP/IP is to JDBC clients today.

No comments: