在现有的版本编码格式使用了两年之后，从 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。版本号之间留出的数字将用于安全警报补丁的发布，这样就不需要重新编码其他计划好的版本号。
新的版本编码系统旨在采用一种能够区分更新和安全补丁的方式，而且是一种识别要简单许多的方式。