EMT4J Simplifies the Transition From JDK 8 to 11 or 17

The two latest iterations of a long-term support (LTS) release for Java, JDK 11 and JDK 17, introduced a slew of new features to make them more useful to developers. But developer uptick has been surprisingly slow: adoption of JDK 11 has not yet reached 50%, even though it was released nearly five years ago, in 2018. The previous version, JDK 8, reached 80% adoption in four years. 

Clearly, despite the advantages of upgrading, developers have been reluctant. The simplest explanation is that making the switch from JDK 8 to 11 or 17 is substantially more complex than it was for developers to upgrade to JDK 8 from 6 or 7. Some of the complicating factors include:

• The deletion of some packages such as sun.misc.\* results in ClassNotFoundException in the running code.
• Changes in the schema of the Java Version cause an exception to the original logic for determining the Java version.
• User code that calls private APIs, and the API is marked as obsolete.
• The introduction of the Java Platform Module System (JPMS) has caused the failure of some reflection code.
• J2EE-related packages have been deleted.
• The addition of over 100 features between Java 8 and 11, some of which introduced incompatibilities.

This is why the Eclipse Migration Toolkit for Java (EMT4J) project was created. 

Enhanced Tooling Makes Upgrading Faster and Easier

The EMT4J project is currently in incubation at the Eclipse Foundation as a subproject of Eclipse Adoptium. The objective of the project was to make the switch from JDK 8 to either 11 or 17 easier and faster for developers. 

JDK 11 and 17 both offer numerous advantages over JDK 8, including: 

• Performance improvements, especially in GC scope
• G1 is now the default GC server
• Substantial enhancements to G1
• New syntaxes, such as Text Blocks
• According to current ecological data, JDK 11 is as stable as JDK 8

There are currently three ways to use EMT4J: 

• Java Agent
• Command-line tools
• Maven plugin (Figure 1)

Figure 1: EM4TJ architecture

Each UI has advantages and disadvantages:

• The Java Agent can obtain more runtime context information, provide an accurate call stack, and find more problems.
• The command-line tool is easy to use and does not need to start the application, but there may be false positives.
• The Maven plugin can be integrated into the build phase and find problems in the development phase.

Seven-Step Process Enables Use of EMT4J

The specific upgrade operation can be broken down into seven steps. 

1. Download the EMT4J tool to /home/jdk17 and install the target version of JDK 17.

2. Download the app-service-1~app-service-8 application package to the machine where EMT4J is located and put it in /home/app/deploy directory. Then put the JVM options app-service-1~app-service-8 into the text file of .cfg in the /home/app/vmoptions directory.

3. Run a tool check: sh ${EMT4J_HOME}/bin/analysis.sh -f 8 -t 17 -j /home/jdk17 /home/app, where -f 8 -t 17 indicates the upgrade from 8 to 17, -j /home/jdk17 indicates the installation directory of the target version JDK, and /home/app indicates the application package and parameter file to be checked. After the command is executed, report.html is generated in the current directory by default. Opening the check report report.html could, for example, display the following list of problems:

4. If you encountered any problems, this is the time to fix them. For example, if we click on “The schema of java version changed in JDK9” to view the details of the problem, we might see the following specific classes: Location:

file:/home/app/deploy/app-service-1/notify-utils-2.2.5.jar,

Target: com.app.services1.utils.VersionInfo.

5. Opening the app-service-1 project could display the following code, which cannot handle a version number similar to 17.0.1:

private final String JAVA_VERSION =

System.getProperty("java.version");

private final int getJavaVersionAsInt() {

if (this.JAVA_VERSION == null)

     return 0; 

     String str = this.JAVA_VERSION.substring(0, 1);

     str = str + this.JAVA_VERSION.substring(2, 3);

     if (this.JAVA_VERSION.length() >= 5) {

          str = str + this.JAVA_VERSION.substring(4, 5);

     } else {

          str = str + "0";

     } 

     return Integer.parseInt(str);

}

6. This is where the information in the report becomes useful. In this case, it explains that the schema of the Java version has changed since JDK 9 and how to modify the code to make it fit the new schema.

7. After revising any other issues, you can use the target version JDK startup on the development machine to verify the accuracy of any function.

Work Continues to Improve EMT4J

There have been some recent improvements to the tool that are worth mentioning. This includes the addition of two new features:

• Support for external tools
• A new option, priority, to specify the rule priority limit

We also combined the solution of AddExportsRule, and introduced some bug fixes as well:

• Preventing escape characters in HTML reports
• Recording a dependency of WHOLE_CLASS in recordLoadClass
• Fixed the issue of getSimpleName not working for anonymous classes

And, obviously, work continues to improve EMT4J. Some relatively important features we are currently working on include:

• Strengthening the ability of static analysis
• Adding the ability to use the Maven plugin to run EMT4J’s java agent
• Optimizing the output format

Contributions and Contributors Welcome

If you’re a user of EMT4J and want to help improve the tool, there are a couple of key issues to look out for:

• There are still some compatibility problems that EMT4J can't find currently
• The problem context reported by EMT4J may be inaccurate and instead obscure the real problem
• The solution description provided by EMT4J may be unclear, making it difficult to modify the code to fix the problem

If you encounter any of these issues, there are two main ways you can help: 

• Create an issue describing the problem you’re experiencing
• Submit a PR that modifies the analysis and tests

Of course, we also hope more developers will participate in the project and help it continue to improve. There are undoubtedly many compatibility problems we have not yet encountered, and as new JDK versions are released, new issues and opportunities for improvement will arise. 

Check out our GitHub for more details on how to use EMT4J or contribute to it, and sign up for our mailing list to keep up to date on the project.