EMT4J——让 Java 应用升级更轻松

简介： EMT4J 是什么？如何使用 EMT4J 工具进行 Java 应用升级？

前言

JDK 升级对于 Java 应用来说是不得不面对的事情，一方面 Java 生态系统希望 Java 应用能跟上最新 JDK 版本：

• Oracle 建议将 JDK 的 LTS 版本的发布周期从 3 年调整为 2 年,对于只使用 LTS 版本的应用来说,可以在更短时间内使用最新的技术，但这也意味着版本升级会更加频繁。
• Spring Framework 6 只支持 JDK 17。Spring 是大多数企业级应用依赖的基础框架，意味着不得不升级到 JDK 17。

但是另一方面，现实中的 Java 应用的 JDK 升级较为缓慢。JDK 11 从 2018 年发布近 4 年，已升级 JDK 11 仍未达到半数（2022-state-of-java-ecosystem）。而相比之下，JDK 8 发布之后 1 年内可达到 38%，两年达到 64.3%，到 2018 年时近 80%(java-8-adoption-march-2016、jvm-ecosystem-report-2018)。

那为什么升级 JDK 11 积极性不高呢？

可能的原因是多方面的。例如 JDK 8 在语言层面引入了 Lambda 对开发人员非常有吸引力，而 JDK 11 在语言层面的更新显得可有可无。但是有一点是非常明显的，相比从其它版本升级到 JDK 8（JDK 6/7 升级到 JDK 8 对于应用基本无感），升级到 JDK 11/17 难度会大很多，可能会遇到很多兼容性问题，如：

1、删除了一些 API 如 sun.misc.*导致代码出现 ClassNotFoundException。

2、Java Version 的 Schema 发生变化导致原来判断 Java 版本的逻辑出现异常。

3、用户代码中使用了私有的 API，使用了标记为废弃的 API 等。

4、JPMS（Java Platform Module System）的引入导致一些反射代码会无法工作。

5、删除了 J2EE 相关的包。

如果需要升级的应用依赖了成百上千的二方和三方 jar，而这些 jar 可能也存在兼容性问题，更进一步，如果需要升级的应用几十个甚至几百个，那么带来的额外工作量可想而知。

正是由于上述的困难，阿里巴巴内部将这些升级的经验通过工具沉淀下来，希望能够通过工具帮忙更多的 Java 应用更高效的升级最新版本 JDK。

EMT4J 简介

目前 Eclipse Migration Toolkit for Java（简称“EMT4J”）已经在 Eclipse 社区开源，并通过了 Eclipse Adoptium PMC 评审，作为 Eclipse Adoptium 子项目进行孵化。阿里云也是 Eclipse Adoptium 工作组的战略基石成员，参与 Eclipse Adoptium 社区治理，为 Java  Ecosystem 提供完全兼容的、基于 OpenJDK 的高质量 JDK 发行版。

EMT4J 目前支持了从 JDK 8 升级到 JDK 11&17 的分析，后续也会不断的更新对于最新的 LTS 版本的支持。

目前支持通过如下 3 种方式使用：

• Java Agent
• 命令行工具
• Maven插件

EMT4J 架构图如下：

EMT4J——工具使用（场景演示）

以一个常见的场景来说明工具的使用：

开发人员张三接到任务，需要将所在团队负责的 8 个 Java 应用(app-service-1 到app-service-8)从 JDK 8 升级到 JDK 17，那张三在 EMT4J 的帮助下如何升级呢？

具体升级操作我们分以下七步走：
1、张三下载了 EMT4J 工具到本地，并且在 /home/jdk17 本地安装了目标版本的 JDK 17。

2、将 app-service-1~app-service-8 的应用包下载到 EMT4J 所在机器，放在目录 /home/app/deploy，并将 app-service-1~app-service-8 的 JVM 选项放入到 .cfg 的文本文件，放在目录 /home/app/vmoptions。

3、运行工具检查：sh ${EMT4J_HOME}/bin/analysis.sh -f 8 -t 17 -j /home/jdk17 /home/app，其中 -f 8 -t 17 表示从 8 升级到 17， -j /home/jdk17 表示目标版本 JDK 的安装目录，/home/app 表示需要检查的应用包以及参数文件。命令执行完成以后，默认会在当前目录生成 report.html。打开检查报告report.html 查看到问题的列表如下：

4、张三点击"The schema of java version changed in JDK9"查看问题的详情，看到提示如下具体的类：Location: file:/home/app/deploy/app-service-1/notify-utils-2.2.5.jar, Target: com.app.services1.utils.VersionInfo。

5、张三打开 app-service-1 的工程看到如下的代码，下面的代码显然是无法处理类似于 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、张三参考报告中的 How to fix 了解到 JDK 9 以后 Java Version 的 Schema 发生了变化，按新的 Schema 修改代码。

7、张三按依次参考报告中对其它问题修改。修改完成以后，在开发机器上使用目标版本 JDK 启动验证功能正确性。

EMT4J——工具特性一览

以上使用 EMT4J 工具帮助张三从 JDK 8 成功地升级到 JDK 17，那么 EMT4J 工具具有哪些特性？

1、支持 Java Agent、命令行工具以及 Maven 插件等方式使用

• Java Agent 可以获取更多运行时上下文信息，能提供准确调用栈，能发现更多的问题
• 命令行工具方便使用，无须启动应用，但是可能会存在误报
• Maven 插件可以集成在构建阶段，可在开发阶段发现问题

2、支持多种潜在不兼容性问题分析

• JDK 8 到 JDK 11

• JDK Internal API 的使用
• System ClassLoader 不再是 URLClassLoader 子类
• Arrays.asList 返回类型变化
• Java Version 的 Shema 发生变更
• JPMS 需要增加 add-exports 和 add-opens
• 时区数据变更为 CLDR 引起相关不兼容
• Pattern.compile 的 API 变更
• JVM 选项变更
• ...

• JDK 11 到 JDK 17

• 删除了 Nashorn
• 删除了RMI 和 Java Applet
• 部分 Class 无法反射获取 Field
• ...

3、支持 HTML、TXT 和 JSON 格式的输出

如何参与贡献？

如果您在使用 EMT4J 的过程中，遇到如下的问题：

• 工具应该发现的兼容性问题，但是实际没有发现
• 工具报告的问题上下文不准确，不方便查找问题在哪里
• 工具报告的问题描述不清晰，难以指导如何修改增加一些新的功能，比如工具支持其它一些格式
• ...

都可以通过如下的方式参与贡献：

• 创建 issue 描述您遇到的问题
• 自己 Fork 以后修改测试后，并通过 PR 合入 master

结语：因为目前还有很多的 Java 应用仍然停留在 JDK 8上，所以这些应用正在规划或者正在升级 JDK 中，希望通过 EMT4J 让我们的升级工作更轻松一些。

我们在工具中沉淀了阿里巴巴升级 JDK 的经验，但是肯定还有很多我们没有遇到的兼容性问题，另外 JDK 新的版本不断会发布，也会不断有新的兼容性问题出来。我们希望通过开源的方式，能够有更多的开发者参与到工具中，给工具不断增强功能,让更多的 Java 应用升级变得更简单。更多内容 (如何使用、贡献等) 可以参考:

https://github.com/adoptium/emt4j

—— 完 ——

加入龙蜥社群

加入微信群：添加社区助理-龙蜥社区小龙（微信：openanolis_assis），备注【龙蜥】与你同在；加入钉钉群：扫描下方钉钉群二维码。欢迎开发者/用户加入龙蜥社区（OpenAnolis）交流，共同推进龙蜥社区的发展，一起打造一个活跃的、健康的开源操作系统生态！

关于龙蜥社区

龙蜥社区（OpenAnolis）由企事业单位、高等院校、科研单位、非营利性组织、个人等在自愿、平等、开源、协作的基础上组成的非盈利性开源社区。龙蜥社区成立于 2020 年 9 月，旨在构建一个开源、中立、开放的Linux 上游发行版社区及创新平台。

龙蜥社区成立的短期目标是开发龙蜥操作系统(Anolis OS)作为 CentOS 停服后的应对方案，构建一个兼容国际 Linux 主流厂商的社区发行版。中长期目标是探索打造一个面向未来的操作系统，建立统一的开源操作系统生态，孵化创新开源项目，繁荣开源生态。

目前，Anolis OS 8.6 已发布，更多龙蜥自研特性，支持 X86_64 、RISC-V、Arm64、LoongArch 架构，完善适配 Intel、兆芯、鲲鹏、龙芯等芯片，并提供全栈国密支持。

欢迎下载：

https://openanolis.cn/download

加入我们，一起打造面向未来的开源操作系统！

https://openanolis.cn

原文链接：https://click.aliyun.com/m/1000351846/

本文为阿里云原创内容，未经允许不得转载。