Java 11+为何移除JRE？如何应对？

Question

Java 11为何移除JRE？这对应用部署有何影响，应如何应对？随着模块化系统的引入，Oracle将JRE从Java 11+中移除，仅提供JDK和精简的运行时镜像（通过jlink）。此举旨在提升安全性和可维护性，避免冗余组件。然而，传统项目依赖完整JRE运行，导致迁移困难。开发者需重构构建流程，使用jlink生成定制运行时，或改用JRE替代方案（如Adoptium的Eclipse Temurin）。如何平滑过渡至无JRE环境，成为升级Java 11+的关键挑战。

Answer 1

Java 11为何移除JRE？对应用部署的影响与应对策略

1. 背景：从JRE到模块化系统的演进

在Java发展的早期阶段，JDK（Java Development Kit）和JRE（Java Runtime Environment）是两个独立分发的组件。JRE仅包含运行Java程序所需的类库和JVM，而JDK则在此基础上增加了编译器、调试工具等开发组件。

随着Java 9引入了JPMS（Java Platform Module System），Java平台开始支持模块化设计。这一变革使得开发者可以按需加载模块，而非加载整个庞大的rt.jar。到了Java 11，Oracle正式决定不再单独发布JRE，而是将JDK作为唯一官方发行版本。

2. 移除JRE的核心动因

• 提升安全性：减少不必要的类库暴露，降低攻击面。
• 优化维护成本：统一构建、测试和发布流程，避免双轨制带来的复杂性。
• 推动模块化落地：通过jlink等工具生成最小化运行时镜像，提升启动性能和资源利用率。
• 适应云原生趋势：容器化部署要求更小、更轻量的运行环境。

3. 对传统应用部署的实际影响

影响维度	具体表现	典型场景
部署包体积	使用完整JDK导致镜像膨胀	Docker镜像大小翻倍
启动时间	加载冗余模块拖慢冷启动	微服务快速扩缩容受阻
兼容性风险	反射访问受限于模块封装	Spring Boot老版本异常
CI/CD流程	需重构构建脚本以支持jlink	Jenkins流水线调整
运维监控	工具链依赖JRE路径失效	JMX连接配置错误

4. 应对方案一：使用jlink构建定制运行时

jlink是Java 9引入的关键工具，允许将JDK拆解并重新组合成一个仅包含所需模块的精简运行时。例如：

# 示例：为Spring Boot应用生成最小运行时
$JAVA_HOME/bin/jlink \
    --module-path $JAVA_HOME/jmods \
    --add-modules java.base,java.logging,java.xml,jdk.unsupported \
    --output ./custom-runtime \
    --compress=2 \
    --no-header-files \
    --no-man-pages
    

该命令生成的custom-runtime目录仅包含约50MB的内容，相比完整JDK可节省60%以上空间。

5. 应对方案二：采用第三方JRE替代方案

社区提供了多个兼容Java SE标准的运行时实现，其中主流选择包括：

• Eclipse Temurin（原AdoptOpenJDK）：由Eclipse基金会维护，提供完整的JRE分发包。
• Azul Zulu：支持多平台，提供企业级补丁和长期支持。
• Amazon Corretto：AWS推出的免费OpenJDK发行版，自带JRE。

这些方案可在不修改现有构建逻辑的前提下实现平滑迁移。

6. 构建流程重构建议

为适应无JRE环境，推荐以下CI/CD优化路径：

1. 评估项目依赖的Java模块列表（可通过jdeps分析）
2. 在Maven或Gradle中集成jlink插件（如moditect-maven-plugin）
3. 定义profile用于生成不同环境的运行时镜像
4. 结合Docker Multi-stage Build，在最终镜像中仅复制定制运行时
5. 自动化测试验证模块边界访问合法性
6. 更新文档与团队培训材料，强调模块封装原则

7. 迁移过程中的常见问题与诊断方法

// 典型错误示例：IllegalAccessError
Exception in thread "main" java.lang.IllegalAccessError: 
class com.example.Util tried to access method java.lang.Object.finalize() 
from class com.another.Lib

// 根本原因：模块系统阻止跨模块访问非导出包
// 解决方式：添加--add-opens参数或重构代码
    

8. 可视化迁移路径：从JRE到模块化运行时

graph TD
            A[传统部署: JRE + WAR] --> B{升级决策点}
            B --> C[jlink生成定制runtime]
            B --> D[切换至Temurin/Zulu JRE]
            C --> E[构建最小化Docker镜像]
            D --> F[保持现有CI/CD不变]
            E --> G[生产部署]
            F --> G
            G --> H[持续监控模块兼容性]

9. 长期战略思考：面向未来的Java运行时管理

随着GraalVM原生镜像、Project Leyden（静态化运行时）等新技术的发展，Java平台正逐步向“超轻量级”演进。企业应建立运行时治理规范，包括：

• 制定模块白名单策略
• 定期审计第三方库的模块声明
• 在SRE体系中纳入运行时指纹管理
• 探索JVM Ahead-of-Time编译的可能性

这不仅关乎Java 11升级本身，更是现代化应用架构转型的重要一环。