在现有的版本编码格式使用了两年之后，从Java 9开始，Java版本方案将根据业内软件版本编码的最佳实践进行修改。使用或解析Java版本字符串的应用程序开发人员要注意了，因为这种变化可以会影响他们的应用程序。

正如JEP 223所阐述的那样，当前的版本方案会跳过某些版本号，而且安全补丁版本和更新版本混在一起。社区认为，该方案产生的版本号含义模糊、不直观。为了解决这个问题，Oracle引入了一种使用语义版本编码的新版本方案，就是说，Java版本字符串将依次包含如下三个部分：主版本号、小（维护）版本号和安全版本号。长版本格式还将包含像构建版本号和可用性这样的信息。

主版本号即我们通常所理解的Java版本，比如，Java 9的主版本是9。因此，按照Java的新版本发布计划，主版本的变化只会两年或三年发生一次。主版本的变化可能会包含破坏性变更，但这些变更至少会提前两个主版本通知。

小版本号将包含非重要Bug修复、所支持API的维护发布以及增加内部组件，如新的服务提供程序、新的垃圾收集器，或者支持新的架构。同更新补丁集一样，小版本有望每季度发布一次。

最后，安全版本将包含重要Bug修复。这些版本可能像重要补丁更新那样根据计划按季度发布，或者像安全警报那样按需发布。

关于这点，有个值得注意的结论是，在认识到社区将当前版本号中的第二个数字作为事实上的主版本号，而开头的1被理解为没有意义之后，Oracle去掉了版本号开头的“1”。这一变化可能会导致目前解析版本字符串而有假定版本号开头为1或点的应用程序出现问题。例如，

System.getProperty("java.version").indexof('.');

上述获取主版本的代码会返回-1（尾部的0会从版本字符串中去掉，因此，9.0.0会简单地表示成9）。

新方案将成为Java版本字符串的第三个标准。第一个始于Java 1.3。该方案相当简单，使用第二个数字作为实际的主版本，第三个数字表明是一个安全修复（奇数）还是更新（偶数）。这种编码系统存在缺陷，有时候会迫使一些版本重新编码。

为了解决这个问题，Oracle引入了当前的版本系统。在当前的方案下，安全补丁仍然使用奇数，更新仍然使用偶数，虽然并不连续。更新总是20的倍数，重要补丁更新的版本通过在最新的维护更新上增加5的倍数（为了保证版本号为奇数，必要的时候要加1）计算得出。这样，如果维护版本号是20，那么按照计划，后续安全版本将是25、31和35。版本号之间留出的数字将用于安全警报补丁的发布，这样就不需要重新编码其他计划好的版本号。

新的版本编码系统旨在采用一种能够区分更新和安全补丁的方式，而且是一种识别要简单许多的方式。

查看英文原文:Java Version Strings Evolve for Java 9