Reasons to change JPA implementation?
I've heard that some people during their careers have changed the JPA implementation in their projects, but what are the reasons? JPA is only an interface, and I would say that it is primitive, compared especially to Hibernate or Toplink's own interfaces. Usually persistence is used in DAOs and most of the stuff is hidden in some GenericDAO, so whenever we want to switch JPA implementation, the only thing necessary is to change GenericDAO and use some custom extensions. Why are people using a raw JPA implementation instead of using the more comfortable interfaces of Hibernate or TopLink? The only profit would be changeability of implementation - am I right? Sorry for my weird questions but I'm new to persistence stuff.
Some reasons to change JPA implementation :
Interesting vendor-specific features
Most JPA vendors implement vendor-specific features outside the JPA spec that developers find convenient enough to use it in a vendor-specific way. (ex: delete-orphan that was longtime hibernate-only). That could be a reason to choose particular vendor, or migrate to that vendor.
Sometimes you might also be forced to change your JPA implementation due to compatiblity issues.
- For example, when migrating to a different Java EE appserver, you may find that your JPA implementation isn't as compliant as you would like it to be, causing issues when configured on that Java EE server, forcing you to use the built-in JPA implementation of that Java EE server. After all, once management has decided to buy an entire stack from Oracle or IBM, and your favorite open source jpa implementation doesn't seem to work on that stack, I bet I know who will be doing the migrating :)
- Even within your project, you might run into compatbility issues. Jboss Seam for example integrates very well with Hibernate, and requires very little setup. Although it is possible to get it up & running with Toplink, I can guarantee you that you will spend much more time debugging issues, and run into a lot more problems.
Company guidelines / policies
Some companies are very strict when it comes to their application architecture.
It might be that
- You are forced to use a specific vendor (ex: Toplink when working in an Oracle environment)
- The company has a policy against using open-source or non-approved libraries.
vendor and/or community support
Another important one is the amount of support you'll be able to get, either from the vendor or from the community. A certain implementation can have a big community behind it, or a commercial vendor can offer great support.
JPA is just a spec, and in an ideal world, it should all be transparent, and we shouldn't care what underlying implementation is being used, but there are always vendor-specific features or issues we need to take into account.