Tuesday, February 3, 2009

The problem with JPA and Java persistence in general...

I just came across another interesting article from a colleague of mine (Billy Newport). Billy has a very active blog on lots of different topics related to Java Development (and a few items not related to programming in the least). But, this one caught my eye due to the title, "The problem with JPA and Java persistence in general..." Surprised by my attention? :-)

I'm not going to try to steal Billy's thunder. If you are interested in debating Billy's viewpoints, you are more than welcome to do so via his blog. I just thought that the content may be of interest to the readers of this blog, so I thought I would cross-post it.

But... I would like to comment that I think the Java EE community has made some great strides in the area of persistence. Not all of the attempts have been welcomed with open arms (ie. CMP Beans), but we really seem to be getting acceptance with the JPA approach. There are several fully-functional implementations of the JPA 1.0 specification, and the JPA 2.0 expert group is extremely active finalizing the next revision of the spec.

So, let me just ask for general comments or suggestions for a Java persistence solution. Is JPA satisfying your persistence needs? What about WebSphere's JPA solution based on OpenJPA? If you are not using it, why not? And, what are you using instead? CMP beans? Straight JDBC? Hibernate? Something else?


1 comment:

Lukas Eder said...

This didn't seem to get too many comments :-)

JPA solves only one set of problems. The problem of trying to persist a "higher-level" OO domain model in a database. It doesn't really leverage SQL as supported by most advanced modern databases.

Other APIs, such as jOOQ (http://www.jooq.org) or MyBatis (http://www.mybatis.org) really try to work SQL into Java. In particular, jOOQ is a reasonable PL/Java implementation, embedding actual SQL as an internal domain-specific language in Java.

JPA with JPQL abstracts that, which is nice in some cases. But often, you need SQL instead, because JPQL renders inefficent queries, or doesn't provide access to SQL features like window functions, grouping sets, etc...