- How to upgrade to Jakarta EE 10 and GlassFish 7 – it’s much easier than you think!
- Upgrade to Jakarta EE 10 – part 1: Transform Applications with Eclipse Transformer
- Upgrade to Jakarta EE 10 – part 2: Transform Application Source Code
- Upgrade to Jakarta EE 10 – part 3: Transform incompatible Dependencies
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, we’ve got you covered! In this post and the future posts in this series, we’ll explain everything you need to know to upgrade to Jakarta EE 10 successfully and almost in no time.
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 tojakarta
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 also 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 have support for Jakarta EE 10 and special adjustments will be needed. Luckily, there are tools to automate this, both on source code level and binary (byte code) level.
Existing tools to automate upgrade steps
Fortunately, many of the challenges can be automated using free and opensource 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 just 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 version that is compatible 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 opensource, 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, we’ve created a repository with examples how to upgrade some existing applications: https://github.com/OmniFish-EE/samples-upgrade-jakarta-ee
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.
In the following articles, we’ll lead you in detail how to address all of the challenges and guide you to a successful upgrade to Jakarta EE 10 and GlassFish 7. We’ll explain how to use tools like OpenRewrite and Eclipse Transformer effectively. Next, we’ll discuss how to upgrade libraries in your application and address libraries that may be incompatible with Jakarta EE 10. Finally, we’ll provide tips on how to optimize and speed up the build process of your application so that you can continue working productively on your application as before.