1. Introduction

1.绪论

In this article, we’ll discuss the new time-based releases of Java and the impact on all types of developers.

在这篇文章中，我们将讨论Java新的基于时间的版本以及对所有类型的开发者的影响。

Changes to the release schedule include updating the feature delivery and support levels for versions of Java. Overall, these changes are distinctly different from the Java that has been supported by Oracle since 2010.

发布时间表的变化包括更新Java版本的功能交付和支持水平。总体而言，这些变化与甲骨文公司自2010年以来一直支持的Java有明显的不同。

2. Why Six-Month Releases?

2.为什么是6个月的发布？

For those of us used to Java’s historically slow release cadence, this is a pretty significant departure. Why such a dramatic change?

对于我们这些习惯了Java历史上缓慢的发布节奏的人来说，这是个相当重大的变化。为什么会有如此大的变化？

Originally, Java defined its major releases around the introduction of large features. This had a tendency to create delays, like those we all experienced with Java 8 and 9. It also slowed language innovation while other languages with tighter feedback cycles evolved.

最初，Java围绕大型功能的引入来定义其主要版本。这有造成延迟的倾向，就像我们在Java 8和9中所经历的那样。它还减缓了语言的创新，而其他具有更紧密反馈周期的语言却在不断发展。

Simply put, shorter release periods lead to smaller, more manageable steps forward. And smaller features are easier to adopt.

简单地说，较短的发布期会带来更小的、更易于管理的前进步伐。而较小的功能则更容易被采用。

Such a pattern pairs well in current conditions and allows JDK development to work in agile methodologies akin to the community it supports. Also, it makes Java more competitive with runtimes like NodeJS and Python.

这样的模式在目前的条件下很好地配对，并允许JDK开发以类似于它所支持的社区的敏捷方法学工作。此外，它还使Java在与NodeJS和Python等运行时的竞争中更具优势。

Of course, the slower pace also has its benefits, and so the six-month release cycle also plays a role in a larger Long Term Support framework, which we take a look at in Section 4.

当然，较慢的节奏也有它的好处，因此六个月的发布周期也在更大的长期支持框架中发挥了作用，我们在第4节看一下。

3. Version Number Change

版本号变化

A mechanical aspect of this change is a new version-number scheme.

这一变化的一个机械方面是一个新的版本号计划。

3.1. JEP 223 Version-String Scheme

3.1 JEP 223版本字符串方案

We’re all familiar with the old one, codified in JEP 223. This scheme made version numbers incremental and relayed extra information.

我们都熟悉旧的方案，编入JEP 223中。这个方案使版本号递增，并传递了额外的信息。

   Actual                    Hypothetical
Release Type           long               short
------------           ------------------------ 
Security 2013/06       1.7.0_25-b15       7u25
Minor    2013/09       1.7.0_40-b43       7u40
Security 2013/10       1.7.0_45-b18       7u45
Security 2014/01       1.7.0_51-b13       7u51
Minor    2014/05       1.7.0_60-b19       7u60

If we run java -version on a JVM for version 8 or older, we’ll see something like:

如果我们在一个版本为8或更早的JVM上运行java -version ，我们会看到这样的情况：

>java -version
java version "1.6.0_27"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0_27-b07)
Java HotSpot(TM) Client VM (build 1.6.0_27-b13, mixed mode, sharing)

In this case, we might guess this is for Java 6, which is correct, and the 27th update, which is wrong. The numbering scheme isn’t as intuitive as it appears.

在这种情况下，我们可能会猜测这是针对Java 6的，这是正确的，而第27次更新则是错误的。这个编号方案并不像它看起来那么直观。

Minor releases were multiples of 10, and security releases filled everything else. Typically, we would see the short string appended onto our local installations, such as JDK 1.8u174. The next release may be JDK 1.8u180, which would be a minor release with new fixes.

次要版本是10的倍数，而安全版本则填补了其他的内容。通常情况下，我们会在本地安装中看到简短的字符串，例如JDK 1.8u174.下一个版本可能是JDK1.8u180，这将是一个带有新修复的小版本。

3.2. New Version-String Scheme

3.2 新版本字符串方案

The new version-string scheme will “recast version numbers to encode not compatibility and significance but, rather, the passage of time, in terms of release cycles,” according to Mark Reinhold in the JEP.

新的版本字符串方案将”重播版本号，不是对兼容性和重要性进行编码，而是对时间的流逝进行编码，就发布周期而言，“根据Mark Reinhold在JEP中的说法。

Let’s take a look at some:

让我们来看看一些。

9.0.4
11.0.2
10.0.1

At a quick glance this appears to be semantic versioning; however, this is not the case.

乍一看，这似乎是semantic versioning；然而，事实并非如此。

With semantic versioning, the typical structure is $MAJOR.$MINOR.$PATCH, but Java’s new version structure is:

在语义版本管理中，典型的结构是$MAJOR.$MINOR.$PATCH，但Java的新版本结构是。

$FEATURE.$INTERIM.$UPDATE.$PATCH

$FEATURE is what we might think of as the major version, but will increment every six months regardless of compatibility guarantees. And $PATCH is for maintenance releases. But, this is where the similarities stop.

$FEATURE是我们可能认为的主要版本，但无论是否有兼容性保证，每六个月都会递增。而$PATCH是用于维护版本。但是，相似之处也就到此为止了。

First, $INTERIM is a placeholder, reserved by Oracle for future needs. For the time being, it will always be zero.

首先，$INTERIM是一个占位符，由Oracle为未来的需要保留。就目前而言，它将永远是零。。

And second, $UPDATE is time-based like $FEATURE, updating monthly after the latest feature release.

其次，$UPDATE和$FEATURE一样是基于时间的，在最新的功能发布后每月更新一次。

And finally, trailing zeros are truncated.

最后，尾部的零被截断了。

This means that 11 is the release number for Java 11, released in September 2018, 11.0.1 is its first monthly update release in October, and 11.0.1.3 would be a hypothetical third patch release from October’s version.

这意味着11是2018年9月发布的Java 11的版本号，11.0.1是其10月的第一个月度更新版本，而11.0.1.3将是10月的版本中假设的第三个补丁版本。

4. Multiple Version Distributions

4.多个版本的分布

Next, let’s look at how to pick the right version.

接下来，让我们看看如何挑选正确的版本。

4.1. Stability

4.1.稳定性

Simply put, Java now has a fast channel, every six months, and a slow channel, every three years. Each third-year release is called an LTS release.

简单地说，Java现在有一个快速通道，每六个月一次，还有一个慢速通道，每三年一次。 每一个第三年的版本被称为LTS版本。

On the fast channel, the language releases features in incubation. These language features stabilize in the LTS release.

在快速通道上，语言发布的功能处于孵化期。这些语言功能在LTS版本中趋于稳定。

So, for companies that can embrace volatility in exchange for using new features, they can use the fast channel. For enterprises that appreciate stability and can wait to upgrade, they can upgrade at each LTS release.

因此，对于那些可以接受波动性以换取使用新功能的公司，他们可以使用快速通道。对于那些欣赏稳定性并能等待升级的企业来说，他们可以在每个LTS版本中进行升级。

Experimentation with JDK versions enables developers to find the best fit.

对JDK版本的实验使开发者能够找到最适合的版本。

4.2. Support

4.2.支持

There’s also, of course, the matter of support. Now that Java 8 support has sunset, what do we do?

当然，还有一个问题，就是支持问题。现在对Java 8的支持已经日落西山，我们该怎么做？

And as discussed earlier, the answer comes in LTS versions, Java 11 being the most recent LTS release and 17 being the next. Updates will be available and supported by vendors such as Oracle and Azul.

而正如前面所讨论的，答案是LTS版本，Java 11是最新的LTS版本，17是下一个版本。更新将由甲骨文和Azul等供应商提供和支持。

If we can trust the support of the community, then Redhat, IBM, and others have stated their support for applying bug fixes for OpenJDK. Also, the AdoptOpenJDK project provides pre-built binaries for OpenJDK.

如果我们可以相信社区的支持，那么Redhat、IBM和其他公司已经声明他们支持为OpenJDK应用错误修复。另外，AdoptOpenJDK项目为OpenJDK提供了预构建的二进制文件。

4.3. Licensing

4.3.许可证制度

One area of confusion for some is the difference between OpenJDK and Oracle JDK.

一些人感到困惑的一个方面是OpenJDK和Oracle JDK之间的区别。

Actually, they are nearly identical, differing only in which bug fixes and security patches have been picked up, according to Brian Goetz.

实际上，它们几乎是相同的，区别只在于哪些错误修复和安全补丁被选中了，根据Brian Goetz的说法。

OpenJDK acts as the source of most derived JDKs and remains free. Starting with Java 11, Oracle will charge commercial license fees for the Oracle JDK with additional support and services included.

OpenJDK作为大多数派生JDK的来源，仍然是免费的。从Java 11开始，Oracle将对Oracle JDK收取商业许可费，其中包括额外的支持和服务。

4.4. Fragmentation

4.4.碎片化

With more frequent releases, fragmentation may become an issue. Hypothetically, everyone could be running on different versions of Java with different features even more so than now.

随着更频繁的发布，碎片化可能成为一个问题。假设，每个人都可能在不同版本的Java上运行，甚至比现在更多的功能。

Of course, containerization could help address this. From Docker and CoreOS to Red Hat’s OpenShift, containerization provides the needed isolation and no longer forces one installation location for Java to be used across the server.

当然，容器化可以帮助解决这个问题。从Docker和CoreOS到红帽的OpenShift，容器化提供了所需的隔离，不再强迫整个服务器使用一个Java的安装位置。

5. Conclusion

5.总结

In conclusion, we can expect a lot more from the Java team at Oracle with a regular release of Java every six months. As a Java developer, the prospect of new language features every six months is exciting.

总之，我们可以期待甲骨文公司的Java团队在每六个月定期发布一次Java的情况下有更多的收获。作为一个Java开发者，每六个月一次的新语言功能的前景是令人兴奋的。

Let’s keep in mind some of the implications as we decide what our upgrade channel is if we need support and licensing, and how to cope with fragmentation.

当我们决定我们的升级渠道是什么时，如果我们需要支持和许可，以及如何应对碎片化，让我们牢记一些影响。