在现有的版本编码格式使用了两年之后,从Java 9开始,Java版本方案将根据业内软件版本编码的最佳实践进行修改。使用或解析Java版本字符串的应用程序开发人员要注意了,因为这种变化可以会影响他们的应用程序。
正如JEP 223所阐述的那样,当前的版本方案会跳过某些版本号,而且安全补丁版本和更新版本混在一起。社区认为,该方案产生的版本号含义模糊、不直观。为了解决这个问题,Oracle引入了一种使用语义版本编码的新版本方案,就是说,Java版本字符串将依次包含如下三个部分:主版本号、小(维护)版本号和安全版本号。长版本格式还将包含像构建版本号和可用性这样的信息。
主版本号即我们通常所理解的Java版本,比如,Java 9的主版本是9。因此,按照Java的新版本发布计划,主版本的变化只会两年或三年发生一次。主版本的变化可能会包含破坏性变更,但这些变更至少会提前两个主版本通知。
小版本号将包含非重要Bug修复、所支持API的维护发布以及增加内部组件,如新的服务提供程序、新的垃圾收集器,或者支持新的架构。同更新补丁集一样,小版本有望每季度发布一次。
最后,安全版本将包含重要Bug修复。这些版本可能像重要补丁更新那样根据计划按季度发布,或者像安全警报那样按需发布。
关于这点,有个值得注意的结论是,在认识到社区将当前版本号中的第二个数字作为事实上的主版本号,而开头的1被理解为没有意义之后,Oracle去掉了版本号开头的“1”。这一变化可能会导致目前解析版本字符串而有假定版本号开头为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。版本号之间留出的数字将用于安全警报补丁的发布,这样就不需要重新编码其他计划好的版本号。
新的版本编码系统旨在采用一种能够区分更新和安全补丁的方式,而且是一种识别要简单许多的方式。