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 126.96.36.199 release of the migration toolkit.
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.
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.
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.
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.