Is it feasible and or recommended to support two JPA implementations?

Question

We have an app that we are developing and we are considering supporting two different JPA implementations.

At the moment we are using openjpa and have fairly well tested code.

I swapped in toplink, ran the tests, and found a bunch of failures.

You'd think that because JPA is a standard there shouldn't be any differences!

The rationale for supporting two JPA implementations is so that we can run on multiple app servers.

So 1stly, is it true that there is a one-to-one mapping between implementation and server. i.e. can I use toplink on WAS for example, or openjpa on Glassfish?

The 2nd question before I investigate the various failures further is, the JPA spec, is it so broad as to make supporting two implementations impractical? Should I even bother trying to make the code work with both?

Answer 1

Usually, a JPA implementation is a superset of the specification. If you are careful to minimize the dependency on vendor specific features, the application should be portable.

But in practice there can be subtle differences between implemantations which make it hard to make an application truly cross-JPA.

In my opnion it is best to stick to the standard as much as possible so that porting to an other JPA implementation should be possible with minimal changes. If you are developing an application for a specific company in a specific context it does not make much sense to test it against multiple JPA implementations and vice versa.

Answer 2

No, it's not true - application servers do not enforce any JPA implementations and you should be able to use OpenJPA with various application servers. Just like you can use Hibernate anywhere you can use any other JPA implementation. Yes, you may have some jar conflicts and troubleshooting to get done before things get right...

No, it's not impractical to make your code work for two or more JPA implementations. But the purpose of this exercise without concrete need is rather impractical. In general, you are better off picking JPA implementation that satisfies your requirements the best... But, again, I can imagine circumstances when using different JPA implementations interchangeably may become a necessity: customer requirements, license constraints, different database support, different platform support (e.g. mobile, embedded, ...).

Answer 3

We noticed the same thing when we were using TopLink Essentials and migrated to EclipseLink. Our code broke in many places even though EclipseLink is based on the same code base!

We have found out that most of the cases were due to the fact that TopLink Essentials didn't adhere fully to JPA specification (for example native queries return List of Vectors etc.). I would expect that the portability between EclipseLink and Hibernate would be better, but probably not perfect.

In some point of time you will probably want to use some vendor specific extensions, such as caching. For this reason I would recommend to pick a JPA provider and first use only functionality specified in the JPA spec. If after a while you are still happy with the specific provider, stick with it and start to take advantage of vendor specific functionality.

I don't think your choice of application server limits your JPA options or vice versa. At least I'm not aware of any limitations.