How To Upgrade to Jakarta EE 10 and GlassFish 7

Upgrading to Jakarta EE 10 from an older version of Jakarta EE or Java EE can be a bit tricky and may require some extra attention to detail. One of the main things you may encounter is making sure your existing code and libraries are compatible. Some libraries may still be using the javax package, which can cause conflicts when trying to run your applications on a Jakarta EE server like Eclipse GlassFish 7. You might also run into problems with some deprecated APIs that were removed in Jakarta EE 10. 

But don’t worry; there are automation tools to help you with the upgrade and examples of how to use them, which I created in the OmniFish GitHub repository.

Types of Challenges

The challenges with upgrading to Jakarta EE 10 or GlassFish 7 fall into these 3 main categories:

• Changing the javax package prefix to jakarta requires updating all references to the old packages
• Obsolete annotations may need to be replaced with alternative annotations
• Rewriting code that uses removed APIs, which don’t have straightforward alternatives

All of the above applies not only to your codebase but to all dependencies used by your application. Many popular libraries already have a new version compatible with Jakarta EE 10, so it’s enough to update them. But some libraries might not support Jakarta EE 10, and special adjustments will be needed. Luckily, there are tools to automate this, both on the source code level and binary (byte code) level.

Existing Tools To Automate Upgrade Steps

Fortunately, many challenges can be automated using free and open-source tools like OpenRewrite, WindUp, and Eclipse Transformer. OpenRewrite is a powerful tool that can automatically make changes to your application’s source code, such as updating all references to the old javax packages with the new jakarta prefix.

In order to use OpenRewrite, you need a recipe for Jakarta EE 10 migration. WindUp provides such a recipe. And not only that. WindUp also provides a UI and can automatically analyze your application, report all the changes needed to upgrade it, and then apply the changes for you, using OpenRewrite under the hood.

Eclipse Transformer, on the other hand, can automatically transform the final JAR, WAR, or EAR binary files. This is useful if you want to try running your older application on a Jakarta EE 10 runtime or if some parts of your application or its dependencies can’t be easily upgraded or refactored.

All these tools can save you time and effort when upgrading to Jakarta EE 10, allowing you to focus on other important aspects of your application’s development. However, it’s still important to review and test the changes made by these tools to ensure that they don’t introduce any unintended consequences.

Dealing With Backwards Incompatible Changes in Jakarta EE 10

It’s important to note that some libraries, mostly those related to Jakarta Faces (JSF), may not yet provide a compatible version with Jakarta EE 10. They may still depend on APIs that have been removed from the platform. It’s essential to identify these libraries in your application and take appropriate action. 

One option is to replace the incompatible libraries with other compatible libraries that provide similar functionality. Another option, if the library is open source, is to rewrite the code of that library so that it doesn’t depend on the removed APIs. In some cases, it may be necessary to provide a compatibility layer to bridge the gap between the old and new APIs, for example, to supply the code of removed APIs directly in your application. This can involve creating a separate module or library that emulates the old APIs and provides the necessary functionality. Regardless of the approach, it’s crucial to address these compatibility issues to ensure that your application runs smoothly on the Jakarta EE 10 platform.

How To Address All of This

As a start, I’ve created a repository with examples of how to upgrade some existing applications.

For example, the javax-jakarta-transform-whole-war example shows how to use the Eclipse Transformer maven plugin to modify the WAR file and the exploded WAR directory to convert everything to use the jakarta. prefix. With this configuration, it’s possible to deploy the resulting WAR file to GlassFish 7 via Admin Console, and it’s also possible to run the application from an IDE like Netbeans and debug it on GlassFish 7 as usual.

You can find further instructions on upgrading your applications easily to Jakarta EE 10 in my article series called Upgrading to Jakarta EE 10 at the OmniFish blog. It currently covers the following topics:

• Transform Applications with Eclipse Transformer
• Transform Application Source Code

In the near future, I'll be adding more articles to cover more details, like how to upgrade dependencies to Jakarta EE 10, how to transform them if needed, and how to refactor your code to remove usage of APIs removed in Jakarta EE 10. I hope that this series of articles will help you upgrade to Jakarta EE 10 easily and in a very short time.