Java Persistence API (JPA) providers map Java objects to data in a relational database to enable applications to write, retrieve, and manipulate data in the database.
With the introduction of JPA 2.1 in the Liberty profile May Beta, we’ve decided to make EclipseLink our JPA provider going forward, while continuing to support OpenJPA for existing customers’ applications.
Why introduce a new JPA provider?
In the recent May Beta of Liberty profile, we introduced the beta version of our JPA 2.1 support (as well as several other beta versions of Java EE 7 technologies).
Part of the JPA specification is to provide support for alternative JPA providers. WebSphere has supported this ability of plugging in alternate JPA providers since the beginning. So using an alternative JPA provider is not a new idea for WebSphere.
Why EclipseLink JPA provider?
Until now, the WebSphere JPA solution has been based on the Apache OpenJPA platform, which has served us well over the years. We know, however, of many WebSphere customers that currently use EclipseLink (or Hibernate) instead of the OpenJPA solution provided by IBM.
Both OpenJPA and EclipseLink are solid open source implementations of the JPA specification. But, as we moved into Java EE 7 development and the JPA 2.1 specification, we agreed it was better to join forces with the EclipseLink open source community than to be the primary (sole) developer in the OpenJPA community.
How will EclipseLink be supported by IBM?
We will provide customers with the same great service with EclipseLink as we do with the rest of the WebSphere product. The support for EclipseLink will follow all of the normal procedures for reporting problems (PMRs) and getting fixes (APARs).
Just like with other open source projects, customers are still welcome, and encouraged, to use the support facilities provided by EclipseLink (forums, mailing lists, wikis, documentation, etc). But iFixes and fixpacks for EclipseLink-related issues will be delivered and managed by IBM as part of the WebSphere JPA solution.
What about current applications using OpenJPA?
Current applications using OpenJPA will continue to function as they have in the past. And, of course, the OpenJPA runtime in WebSphere Application Server full profile (WAS) will continue to be supported for as long as JPA 1.0 and JPA 2.0 are supported in WAS (ie, for the foreseeable future).
From a Liberty perspective, the
jpa-2.0 feature will use OpenJPA by default, while the
jpa-2.1 feature will use EclipseLink by default.
You can decide if or when the move to EclipseLink is warranted for your Liberty profile applications. If the current functional level of OpenJPA is sufficient for your needs, then you should stick with the
jpa-2.0 feature. Even if you are using our other Beta levels of Java EE 7 technologies, you can continue to use the
If you decide to move up to the JPA 2.1 specification level, however, you will probably have to do some application migration.
Will I need to change my applications to move to JPA 2.1?
The impact on your application when moving to JPA 2.1 will depend on how well you were able to stick to the JPA programming model. If you coded to the specification and didn’t use any (or very few) OpenJPA extensions, then your migration should be relatively straightforward.
If this describes your environment, then my suggestion would be to just configure the
jpa-2.1 feature and try it out. You may be pleasantly surprised by the ease of migrating from OpenJPA to EclipseLink.
Of course, this scenario may be too simple for many JPA users. Most JPA applications have had to go outside of the scope of the specification for one reason or another (this applies to every JPA provider, not just OpenJPA). The extensions in use will range from simple property usage (for example, configuring caches) to more extensive programming model use (for example, using fetch plans and fetch groups).
Most of the WebSphere JPA extensions will have a corresponding feature available in EclipseLink, either as part of the JPA 2.1 standard or as an EclipseLink extension.
Eventually, we will have migration utilities and documentation to help you with this move from OpenJPA to EclipseLink. For now, though, with this Beta, we’re focusing on providing the JPA 2.1 level of support.
As you begin experimenting with our EclipseLink support, please provide feedback on your experiences and what features of OpenJPA you were dependent on.
If you prefer to contact us privately, you can send your feedback by email to email@example.com.
Some final thoughts
The decision to use EclipseLink for WebSphere’s JPA 2.1 support was both easy and difficult. Of course, the first thing that came to mind was the perceived migration issue when moving to JPA 2.1.
We have attempted to mitigate that issue by keeping the same level of support in place for our existing OpenJPA solutions for JPA 1.0 and JPA 2.0. As mentioned previously, we are also working on migration aids to help identify the areas of code that may be affected by the introduction of the EclipseLink solution.
We also see this move to EclipseLink for JPA 2.1 as a positive collaboration with the EclipseLink community. We can bring our years of expertise and experience from OpenJPA and our WebSphere customers to the EclipseLink project, making EclipseLink an even better offering.
Becoming participants of the EclipseLink community will strengthen both our near- and long-term JPA solution.