根据Java 9的新版本字符串方案的this blog,版本应该像MAJOR.MINOR.SECURITY
,即,应该有3个数字和2个句点。
但是,使用Azul的Zulu 9,当我打印Java版本时,它有4个数字和3个句点:
./jdk/bin/java -version
openjdk version "9.0.0.15"
OpenJDK Runtime Environment (Zulu build 9.0.0.15+181)
OpenJDK 64-Bit Server VM (Zulu build 9.0.0.15+181, mixed mode)
4个数字代表什么?
答案 0 :(得分:21)
该博客帖子有点过时了。 Java 9中实际实现的方案记录在JEP 223: New Version-String Scheme
中前三个数字的含义是标准化的。第4个和(任何)后续数字的含义留给供应商指定。
还要注意第2和第3个数字之间的有趣关系。
以下是JEP的相关部分。
“序列可以是任意长度,但前三个元素被赋予特定含义,如下所示:
$MAJOR.$MINOR.$SECURITY
$MAJOR
- 主要版本号,针对包含新版Java SE平台规范中指定的重要新功能的主要版本递增,例如JSR 337 for Java SE 8.功能可能会被删除在主要版本中,提前通知至少一个主要版本提前通知,并且在合理的情况下可以进行不兼容的更改。 JDK 8的$MAJOR
版本号为8; JDK 9的$MAJOR
版本号为9.当$MAJOR
递增时,将删除所有后续元素。
$MINOR
- 次要版本号,针对可能包含兼容错误修复的次要更新版本递增,对相关平台规范的维护版本强制要求的标准API进行修订,以及超出范围的实现功能规范,例如新的JDK特定API,附加服务提供程序,新垃圾收集器以及新硬件体系结构的端口。
$SECURITY
- 安全级别,针对包含关键修复程序(包括提高安全性所必需的修复程序)的安全更新发行版进行递增。当$SECURITY
递增时,$MINOR
不会重置为零。因此,对于给定的$SECURITY
值,$MAJOR
的值越高,始终表示更安全的版本,无论$MINOR
的值是什么。版本号的第四个和后面的元素可供JDK代码库的下游使用者免费使用。除了相应安全版本中的安全修复程序之外,这样的消费者可以例如使用第四元素来识别包含少量关键非安全修复的补丁版本。
答案 1 :(得分:8)
即,中间应该有3个数字和2个句点。
不一定,您可以使用JDK本身验证版本,如下所述。
除了other answer中由@Stephen链接的JEP之外,还有一个API添加到JDK以及 Runtime.Version
可用于验证给定的版本字符串。这可以使用示例存根完成:
[我想在这里使用JShell会很有趣,没有IDE!]
Runtime.Version version = Runtime.Version.parse("9");
version = Runtime.Version.parse("9.0.1");
version = Runtime.Version.parse("9.0.0.15");
version = Runtime.Version.parse("9.0.0.15+181");
该代码使用了 Version.parse
将给定字符串解析为包含版本的有效版本字符串 数字后跟预发布和构建信息。
可以进一步用于(主要)获取(runtime) version的主要,次要,预发布和安全号码等信息。