OpenJDK 主线新版本启动指南：JDK N 到 JDK N+1 的版本递增改动全清单（基于 jdk 主线仓库 doc/starting-next-release.md）
OpenJDK 主线新版本启动指南JDK N 到 JDK N1 的版本递增改动全清单基于 jdk 主线仓库 doc/starting-next-release.md【免费下载链接】jdkJDK main-line development https://openjdk.org/projects/jdk项目地址: https://gitcode.com/GitHub_Trending/jd/jdk本文基于当前 OpenJDKjdk主线仓库中的官方文档 doc/starting-next-release.md 编写。每当 JDK 主线发布一个新版本例如从 JDK 28 走向 JDK 29都需要执行一组启动新版本start of release的改动将Runtime.version()的 feature 值、javax.lang.model.SourceVersion的最高源版本、平台可识别的最高 class file 主版本号、以及javac等工具可识别的-source/-target/--release参数分别递增同时为--release生成新的符号symbol数据。读完本文你将掌握这些改动涉及的每一类文件、每一个关键常量与其在源码中的真实位置并理解为什么这些改动必须以独立的语义维度分别推进。一、Overview一次版本切换到底改了什么文档开门见山地指出所谓 start of release 改动本质上是把 JDKN变成 JDK (N1)的一批小型文件更新外加新增一批用于符号信息的文件目的是让javac --release N ...能在 JDK (N1) 上继续正常工作。这些改动覆盖三大区域持有 release 元数据的文件构建系统与工具链配置src目录下的 API 与工具链更新HotSpot、java.base、java.compiler、jdk.compiler各模块test目录下的附带更新保证测试矩阵与新版本对齐。按照官方策略以下四个语义上相互独立的概念必须分别递增不能混为一谈概念位置含义Feature 值Runtime.version()JDK 运行时版本号中的主版本号如 28最高源版本javax.lang.model.SourceVersion注解处理器等工具可见的语言版本上限最高 class file 主版本号平台HotSpot/JVM识别上限决定 VM 能否加载该类文件最高-source/-target/--release参数javac及相关工具编译器接受的版本参数上限例如在当前的 jdk 主线仓库中make/conf/version-numbers.conf 显示DEFAULT_VERSION_FEATURE28、DEFAULT_VERSION_CLASSFILE_MAJOR72注释中明确写明取值为$EXPR $DEFAULT_VERSION_FEATURE 44即 28 44 72说明该主线当前处于 JDK 28 开发期启动 JDK 29 时这些值需要同步推进class file 主版本号将变为 73。二、Meta-data 文件构建与工具链的版本元数据2.1make/conf/version-numbers.conf构建系统的版本事实来源该文件是整个构建系统读取版本信息的核心配置文件。文档要求在新版本启动时更新其中的元数据。结合当前仓库内容该文件中的关键条目包括DEFAULT_VERSION_FEATUREfeature 版本号当前为 28DEFAULT_VERSION_INTERIM/DEFAULT_VERSION_UPDATE/DEFAULT_VERSION_PATCHinterim、update、patch 层级当前均为 0DEFAULT_VERSION_EXTRA1/2/3额外的版本扩展位DEFAULT_VERSION_DATE版本日期当前为 2027-03-23DEFAULT_VERSION_CLASSFILE_MAJORclass file 主版本号由feature 44推导当前为 72DEFAULT_VERSION_CLASSFILE_MINORclass file 次版本号当前为 0preview 类文件使用 65535DEFAULT_VERSION_DOCS_API_SINCEAPI 文档标注的起始版本当前为 11DEFAULT_ACCEPTABLE_BOOT_VERSIONS构建时允许作为 boot JDK 的版本集合当前为26 27 28启动新版本后需加入新版本号并通常移除过旧版本DEFAULT_JDK_SOURCE_TARGET_VERSION默认的 source/target 版本当前为 28DEFAULT_PROMOTED_VERSION_PRE预发布标记当前为ea。启动新版本时feature 递增后class file major、boot 版本集合、source/target 版本等条目需要联动更新因为这些值之间存在直接的算术或策略依赖。2.2jcheck/confSkara 工具链的提交检查元数据文档同时要求更新jcheck/conf下的元数据它服务于jcheck与 Skara 工具链OpenJDK 基于 Git 的评审/推送基础设施。该配置用于门禁提交的各类检查规则。需要说明的是当前仓库快照中并未包含该目录内容它通常随启用 Skara 工作流的仓库管理元数据一起维护属于提交基础设施而非构建产物因此不在源码树中展开。三、src目录API、HotSpot 与编译器内部的版本推进3.1 HotSpot 虚拟机classFileParser.cpp中的版本宏文档要求 src/hotspot/share/classfile/classFileParser.cpp 为新的 class file 版本增加一个#define。当前仓库中该文件已按版本连续定义L144-L160#define JAVA_20_VERSION 64 #define JAVA_21_VERSION 65 #define JAVA_22_VERSION 66 #define JAVA_23_VERSION 67 #define JAVA_24_VERSION 68 #define JAVA_25_VERSION 69 #define JAVA_26_VERSION 70 #define JAVA_27_VERSION 71 #define JAVA_28_VERSION 72启动 JDK 29 时只需追加#define JAVA_29_VERSION 73。这些宏随后被用于版本合法性判断例如 L4210-L4211 的检查逻辑return _major_version JAVA_28_VERSION || (_major_version JAVA_28_VERSION _minor_version JAVA_PREVIEW_MINOR_VERSION);可以看到HotSpot 依据主版本号是否超过当前已知最高版本以及主版本号等于最高版本且次版本号为 preview65535来判断是否属于本 VM 尚不支持的未来版本class 文件。此外该文件还定义了JDK_VERSION宏L162#define JDK_VERSION (7 (JVM_CLASSFILE_MAJOR_VERSION - JAVA_7_VERSION))将 class file 主版本号映射回 JDK 版本号因此新增宏时也会间接影响这一推导。3.2java.baseclass file 版本 API文档要求两个java.base文件同步更新src/java.base/share/classes/java/lang/classfile/ClassFile.javaClass-File API 的入口需要为新的 class file 格式版本添加常量。该 API 自 JDK 22 起孵化、后续转正位于java.lang.classfile包是标准库中读写 class 文件的核心工具src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java该枚举建模 class file 的主版本号如类注释 L40-L44 所述JVM 需支持一定范围的 major 版本具体见对应版本的 JVMS。需要为新的格式版本新增一个enum常量。文件头部还以注释形式记录了 class file 格式的演进历史L52-L92从 1.1 的InnerClasses属性一路列到 24 的no changes是了解格式版本与语言特性对应关系的第一手资料。3.3java.compilerSourceVersion与 visitorssrc/java.compiler/share/classes/javax/lang/model/SourceVersion.java需要为新的源版本新增enum常量。当前仓库已包含从RELEASE_20L395到RELEASE_28L513的完整序列并且latestSupported()等方法返回最高受支持版本L523 返回RELEASE_28。新版本启动时在此追加RELEASE_29并同步更新相关查询方法src/java.compiler/share/classes/javax/lang/model/util/*下的各类 visitors需要将其SupportedSourceVersion注解更新为最新值。文档特别强调这一更新是替代为每个 Java SE 版本引入一套新 visitors的做法——也就是说visitors 不随版本机械翻倍而是通过注解提升其声明支持的版本上限这是该文档明确给出的设计取舍。3.4jdk.compilerjavac 内部的三个版本枚举src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.javajavac 内部的源版本枚举当前已定义JDK20(20)至JDK28(28)L130-L170启动新版本时追加JDK29(29)src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.javajavac 内部的 class file 格式版本枚举需为新的主版本号新增常量其中还包含 preview 相关的次版本号常量src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.javajavac 内部的 target 版本枚举同样需要新增常量。这三个枚举是javac校验-source/-target/--release参数合法范围的直接依据三者必须与 HotSpot 与 API 层的版本保持严格一致否则会出现编译器能认但 VM 不能跑或反之的错位。3.5PrintingProcessor.java注解处理输出同步src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java需要更新以支持新的源版本。该处理器用于按注解处理器的 API 重新打印源码模型其内部会基于SourceVersion判断可用的语言特性因此新版本加入后必须同步调整避免在打印时把高版本特性当作非法输入。3.6--release的符号数据src/jdk.compiler/share/data/symbols文档指出--release所需的符号信息以文本文件形式存储于src/jdk.compiler/share/data/symbols目录每个模块、每个版本一个文件。当前仓库中该目录确实存在包含 README、include.list以及大量形如java.base-8.sym.txt、java.base-9.sym.txt、java.base-A.sym.txt……java.base-R.sym.txt、java.compiler-8.sym.txt等按模块与版本命名的.sym.txt文件字母 A、B、C 等是特定历史版本的代号。README 内容如下This directory contains history data for -release. Please see $JDK_TOP_DIR/bin/generate-symbol-data.sh for main usage.也就是说生成这些符号文件的主流程由$JDK_TOP_DIR/bin/generate-symbol-data.sh驱动该脚本属于仓库配套工具链README 指向它作为主要用法入口。启动新版本时需要按照该脚本流程为最新版本生成并提交新的符号数据文件javac --release N才能基于这些数据对旧版本 API 进行编译期约束。四、test目录测试矩阵与新版本对齐文档列出了五个必须同步更新的测试文件它们共同保证新版本在测试层面被完整覆盖test/langtools/tools/javac/api/TestGetSourceVersions.java在测试矩阵中加入新的SourceVersion常量验证javac工具 API 报告的最高源版本正确test/langtools/tools/javac/classfiles/ClassVersionChecker.java为新的 class file 版本新增枚举常量校验javac输出 class 文件的主版本号正确test/langtools/tools/javac/lib/JavacTestingAbstractProcessor.java更新 javac 测试所继承的注解处理器基类使其覆盖新的源版本test/langtools/tools/javac/preview/classReaderTest/Client.nopreview.out与Client.preview.out这两个期望输出文件分别对应非 preview 模式与preview 模式下读取 class 文件时的错误/警告消息新增版本后必须同步更新其中的版本字符串test/langtools/tools/javac/versions/Versions.java在合法源版本集合中加入新版本并为新的 class file 版本新增枚举常量。这些文件分布在test/langtools测试树中与第三部分的源码改动一一对应构成源码改一处、测试跟一处的闭环。五、启动新版本的操作清单小结综合文档与仓库源码一次完整的 start of release 改动可按以下顺序核对元数据层更新make/conf/version-numbers.conffeature、class file major、boot 版本、source/target 默认版本并按需更新jcheck/conf的 Skara 工具链元数据HotSpot 层在 classFileParser.cpp 追加JAVA_N_VERSION宏标准 API 层更新 ClassFile.java、ClassFileFormatVersion.java、SourceVersion.java 及javax.lang.model.util下各 visitors 的SupportedSourceVersionjavac 内部层更新 Source.java、jvm/ClassFile.java、jvm/Target.java与 PrintingProcessor.java符号数据按 symbols/README 指引为--release生成新版本的.sym.txt文件测试层更新文档列出的 5 处test/langtools测试文件使新版本进入测试矩阵。从当前仓库的实际状态feature 28、class file major 72、RELEASE_28、JDK28可以看出这套流程已经历了从 JDK 20 到 JDK 28 的多次完整执行——无论是 HotSpot 中的连续版本宏、SourceVersion中连续的RELEASE_*常量还是symbols目录下按版本命名的文件序列都为下一次启动新版本提供了清晰的增量模式。若你正参与 OpenJDK 主线开发或维护分支版本这份清单可作为提交新版本启动改动时的逐项核对表。【免费下载链接】jdkJDK main-line development https://openjdk.org/projects/jdk项目地址: https://gitcode.com/GitHub_Trending/jd/jdk创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考