A brief summary of what to be aware of if you’re updating your Java EE 6 applications to Java EE 7.

With the Java EE 7 certification of Liberty and traditional WebSphere, you have more choices than ever for running your applications. The Application Evaluation Report, available in the Migration Toolkit for Application Binaries and the Migration Toolkit, has been updated to show additional support of Java EE technologies on our Java EE 7 certified platforms.

With traditional WebSphere V9.0 certification, we have continued to enhance the migration tools around Java EE 7. There are detailed migration analysis rules to help with differences found in CDI, EL, JAX-RS, JMS, JPA and Servlet.

Updating your existing applications to Java EE 7

If you plan to update applications to use the Java EE 7 platform, keep in mind that some of the technologies have behavior differences that are caused by specification clarifications and by changes in the underlying implementation.

See the Java EE 7 behavior changes Knowledge Center article for a consolidated list of the affected features and links to the detailed articles for each. More Java EE 7 behavior differences have been captured in the release of the migration toolkit.

Implementation changes

For Liberty and traditional WebSphere, the Java EE 7 implementations for the following technologies changed:

  • JAX-RS 2.0 is based on CXF whereas JAX-RS 1.1 is based on Apache Wink.
  • CDI 1.2 is based on the Weld implementation whereas CDI 1.0 is based on Apache OpenWebBeans.
  • JPA 2.1 is based on EclipseLink whereas JPA 2.0 is based on OpenJPA.

Implementation changes tend to cause migration issues because as different teams develop a technology, different interpretations of the specification are made and behavior differences are created.

Feature combinations

The fundamental architectural difference between Liberty and traditional WebSphere also affects Java EE 7 migration. Upon installation of traditional WebSphere V9.0, you get the full Java EE 7 platform as the default implementation. In general you cannot pick and choose the feature capabilities you want your application server to have, and you cannot switch back to Java EE 6. The exception for traditional WebSphere V9.0 is that you do have the option of using the Java EE 6 implementation of JAX-RS and JPA. This involves changing the server configuration to use the non-default implementations.

For Liberty, you have more freedom to stay on your Java EE 6 platform. You can also mix and match Java EE 6 and Java EE 7 to the extent allowed as described in the Supported Java EE 6 and 7 feature combinations Knowledge Center article. Some features are dependent on other Java EE 7 features, and moving to them has a ripple effect of required feature changes. You should also note that all Java EE 7 features depend on Java SE 7 or higher.

Should I migrate JPA applications?

As previously mentioned, an example of an exception case is JPA 2.0 (Java EE 6), which can be used with all other Java EE 7 features. Since the migration for JPA is more involved, the recommended action is to keep existing JPA applications running on JPA 2.0 with no application changes.

If you need new JPA 2.1 functionality or you want the new EclipseLink implementation, the Migration Toolkit has a set of rules and quick fixes for migrating JPA applications with data persisted using JPA 2.0 to work properly with JPA 2.1. The Eclipse-based tool focuses on JPA annotation migration differences. It also scans for other OpenJPA to EclipseLink differences. If you use the JPA object-relational mapping file rather than annotations, not all issues will be flagged. Because migrating to JPA 2.1 is optional, only select the JPA rules if you are planning on changing implementations.

Choosing the Migration Rules

When you run the latest Eclipse migration tool, you will notice that you can select a target Java EE version, which allows for selection of technologies that have known differences. Selecting the technology selects the related rules. If your target is Liberty, only select the technologies that are configured on your Liberty server and that you want to migrate to the Java EE 7 version. For example, there is a CDI performance rule that will warn you if projects do not have a beans.xml files to minimize CDI scanning. If you do not have the CDI feature enabled in your server, this rule is not relevant, and you do not need to make any changes. If traditional WebSphere is your target, only JPA and JAX-RS are selectable and the rest are auto-selected. Select JPA or JAX-RS if you plan to use the Java EE 7 implementation of those technologies.

WAMT configuration dialog

The binary scanner allows you to select Java EE 7 as a target but does not allow you to pick individual technologies. Ignore results that do not apply to your application server.

In sum…

As you write new applications for Liberty, take advantage of all the new features and functions the Java EE 7 platform has to offer. For existing applications, though, the Liberty feature architecture gives you the freedom to make no changes and continue your business uninterrupted.

For traditional WebSphere, Version 9.0 gives you all the capabilities of Java EE 7. Version 8.5.5 is available if you want to continue to use the Java EE 6 implementations.

7 Comments on "Updating to Java EE 7"

  1. Kaushik Mukherjee October 13, 2016

    Do you know what version of RAD would I need to move up to WAS v9 for developers?

  2. MartinOberhofer July 01, 2016

    Hi Cindy,
    is there a possibility to run WAS v8.5.6.x and WAS v9 with JDK v8? If so, what would I need to do if I have a RAD v9.5 with a WAS v8.5.5.7 installation to get that done?
    Thanks much in advance.

    • Hi Martin,
      My apologies for missing your question. WAS 8.5.5.x started supporting Java 8 in version So you would need to update your WAS V8.5.5.7 installation to V8.5.5.9, install Java 8, and use the managesdk command to switch your installation to use Java 8. WAS v9 only supports Java 8.


  3. When I run the WebSphere Migration Tool in my Eclipse Juno environment (with Liberty profile) and a codebase that runs on WebSphere 8558 Full profile I don’t see the options you mentioned above as selectable. All the rules are already created and their is no choice to create a new rule. I am using the tool downloaded from: https://developer.ibm.com/wasdev/downloads/#asset/tools-WebSphere_Application_Server_Migration_Toolkit

    I saw a command line tool and this one, maybe there is a third tool?

    • Cindy High March 10, 2016

      Hi Doug,
      The link you provided is the correct link for the Eclipse migration tool. Do you have the December 2015 version installed? Do you not see this dialog at all, or are certain features not present on the dialog?

      To open this dialog from the Software Analyzer Configuration dialog, choose WebSphere Application Server Version Migration from the Rule Sets list. Click Set… You will only see the Java EE 7 Technologies check boxes if you have Liberty or Liberty Core as the target application server and Java EE 7 as your target Java EE version.

      If this doesn’t help, let me know the steps your are taking and what you see at each.


Join The Discussion

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