Using EMT4J to Migrate Java Projects from JDK 8 to JDK 11

When a boss asks to upgrade a project from Java 8 to Java 11, the quick‑and‑dirty approach is to fix errors one by one, which works for tiny, non‑critical codebases; for larger or important projects the recommended method is to follow the official Java 11 migration guide.

The tool that automates this process is EMT4J (Eclipse Migration Toolkit for Java). Its homepage ( https://projects.eclipse.org/projects/adoptium.emt4j ) provides a friendly story about “Tom” migrating his project, and the source code is hosted on GitHub ( https://github.com/adoptium/emt4j ).

After downloading EMT4J, the directory layout is simple:

emt4j-0.3
├── bin
│   ├── analysis.bat
│   └── analysis.sh
└── lib
    ├── agent
    │   ├── emt4j-agent-jdk11-0.3.jar
    │   └── emt4j-agent-jdk8-0.3.jar
    └── ... (other jars)

To analyze a compiled class with the javaagent, run:

java -javaagent:emt4j-agent-jdk8-0.3.jar=to=11 HelloWorld

Then generate a visual HTML report:

sh analysis.sh -o report.html emt4j-XXX.dat

An example Hello World program compiled with JDK 8 and migrated to JDK 11 produces a simple report confirming no compatibility issues.

For a more complex project, EMT4J’s HTML report highlights real migration problems such as the change in the java.version schema and a bug in Log4j’s isPreJava8 method, showing the offending code and the official fix.

Internally, EMT4J uses ASM to parse class files into ClassSymbol objects, then applies a set of MVEL‑based rules (e.g., methodSet.contains('java.lang.System.getProperty') && (cpSet.contains('java.version') || cpSet.contains('java.specification.version') || cpSet.contains('java.runtime.version')) ) to detect compatibility issues. The analysis flow is: AnalysisMain.main → doAnalysis → ClassAnalyzer.processClass → RuleImpl.check → MVEL.eval → Report generation .

The final HTML report is built by looking up official documentation via ResourceBundle , rendering the findings in a developer‑friendly format. The toolkit demonstrates how combining well‑known libraries (ASM, MVEL) can provide a lightweight, extensible solution for JDK migration and can be customized for other compatibility checks.