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 jpa-2.0 feature.

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.

Get the Beta! Ask on Stack Overflow

If you prefer to contact us privately, you can send your feedback by email to

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.

5 comments on"EclipseLink JPA provider for Liberty profile"

  1. Is there now an example that uses the jpa-2.1 feature?

  2. Roman Kharkovski December 10, 2014

    If EclipseLink is the new default JPA provider, why do I need to put 8MB jar file into the shared/resources folder of my server? I would expect this to be part of the core runtime.

    The reason I ask is because when I package the server the eclipselink-2.5.2.jar is in there while packaging with the old JPA provider did not have any extra jars in my server package.

  3. Roman Kharkovski December 02, 2014

    The sample app is configured to use JPA 2.0 and when I change that to JPA 2.1 it gives me an error. Any plans to provide an updated sample app for JPA 2.1?

    Here is the error I get when trying to use JPA 2.1 with the sample (please note that it works fine when I configure JPA 2.01):

    Hello JPA World Creating a brand new Thing Something went wrong. Caught exception javax.persistence.PersistenceException: java.lang.VerifyError: Bad return type Exception Details: Location: org/eclipse/persistence/internal/databaseaccess/DatasourcePlatform.buildNativeCall(Ljava/lang/String;)Lorg/eclipse/persistence/internal/databaseaccess/DatasourceCall; @8: areturn Reason: Type ‘org/eclipse/persistence/queries/SQLCall’ (current frame, stack[0]) is not assignable to ‘org/eclipse/persistence/internal/databaseaccess/DatasourceCall’ (from method signature) Current Frame: bci: @8 flags: { } locals: { ‘org/eclipse/persistence/internal/databaseaccess/DatasourcePlatform’, ‘java/lang/String’ } stack: { ‘org/eclipse/persistence/queries/SQLCall’ } Bytecode: 0000000: bb02 ce59 2bb7 02d0 b0

    • Hi Roman,
      Yes, we are working on updating the simple JPA sample to just use the jpa-2.1 feature that is available in the Liberty Betas. It’s just not quite ready for posting yet.

      In the mean time, you are welcome to visit this sample that demonstrates how to use eclipselink as an alternate JPA provider in Liberty:

      The difference is that this sample packages EclipseLink library with the application instead of using the jpa-2.1 feature. But, the included persistence.xml shows the various EclipseLink specific properties that are required to run within the WebSphere environment.

      Hope this helps,

Join The Discussion

Your email address will not be published. Required fields are marked *