jdk1.8新特性::_首先看一下JDK 13：Rampdown第二阶段，没有针对新的JEP

jdk1.8新特性::

按照JDK的时间表，JDK 13已正式进入开发过程的下一个阶段：欢迎进入Rampdown第二阶段。 这意味着此发行版将没有新的JEP。 特此冻结所有JEP，开发团队将把重点放在P1和P2错误上。

根据Oracle的Mark Reinhold的更新：

批准后仍可能进行后期增强，但现在的门槛非常高。

如果您对RDP 2候选错误列表[3]中的任何错误负责，请参阅JEP 3以获取有关如何处理它们的指南。

在该线程中的先前新闻的目标上刷新您的记忆。

更新2019年6月11日

有必要对此线程进行一次快速更新。

现在，另外两个JEP针对JDK 13，其中包括讨论很多的Switch Expressions（预览）。

让我们刷新一下记忆。

针对JDK 13

简介：扩展switch使其可以用作语句或表达式，以便两种形式都可以使用传统的case ... :标签（带有贯穿）或新的case ... ->标签（不带有贯穿）通过），还有一个新的语句，用于从switch表达式中产生一个值。 这些更改将简化日常编码，并为在switch使用模式匹配（JEP 305）做好准备。 这将是预览语言功能。

描述：

• 箭头标签–除了开关块中的传统“ case L : ”标签外，还提出了一种新的简化形式，带有“ case L -> ”标签。
• 开关表达式– switch语句得到扩展，因此可以用作表达式。
• 产生一个值–大多数开关表达式在“ case L->”开关标签的右侧都有一个表达式。 如果需要一个完整的块，则会引入新的yield语句以产生一个值，该值成为封闭的switch表达式的值。
• 详尽无遗–切换表达式的情况必须详尽无遗； 对于所有可能的值，必须有一个匹配的开关标签。 （显然，switch语句不需要穷举。）

• JEP 355：

摘要：将文本块添加到Java语言。 文本块是一种多行字符串文字，它避免了大多数转义序列的需要，以一种可预测的方式自动设置字符串的格式，并在需要时使开发人员可以控制格式。 这将是预览语言功能。

目标：

• 通过简化表示跨越几行源代码的字符串的工作，简化了编写Java程序的任务，同时避免了常见情况下的转义序列。
• 增强表示非Java语言编写的代码的Java程序中字符串的可读性。
• 通过规定任何新构造都可以表示与字符串文字相同的字符串集，并解释相同的转义序列，并像字符串文字一样进行操作，来支持从字符串文字的迁移。

更新2019年6月3日

我们回来了关于JDK 13开发的最新更新！

这次，我们看到又有两个JEP被提议作为目标，包括讨论很多的Switch Expressions（预览），以及现在以JDK 13为目标的JEP 353。

我们来看一下。

拟定目标

简介：扩展switch使其可以用作语句或表达式，以便两种形式都可以使用传统的case ... :标签（带有贯穿）或新的case ... ->标签（不带有贯穿）通过），还有一个新的语句，用于从switch表达式中产生一个值。 这些更改将简化日常编码，并为在switch使用模式匹配（JEP 305）做好准备。 这将是预览语言功能。

• JEP 355：

摘要：将文本块添加到Java语言。 文本块是一种多行字符串文字，它避免了大多数转义序列的需要，以一种可预测的方式自动设置字符串的格式，并在需要时使开发人员可以控制格式。 这将是预览语言功能。

针对JDK 13

简介：用一个更易于维护和调试的更简单，更现代的实现替换java.net.Socket和java.net.ServerSocket API使用的基础实现。 新的实现将很容易适应与用户模式线程（也称为光纤）一起使用，而Project Loom目前正在研究这种模式。

更新2019年5月17日

我们回来了更多的Java新闻！

今天，我们来看看新提交的JEP候选者以及Brian Goetz本人提交的JEP 353，该对象是针对JDK 13的。

让我们开始吧。

JEP候选人

• JEP 355：

摘要：将文本块添加到Java语言。 文本块是一种多行字符串文字，它避免了大多数转义序列的需要，以一种可预测的方式自动设置字符串的格式，并在需要时使开发人员可以控制格式。 这将是预览语言功能。

目标：

• 通过简化表示跨越几行源代码的字符串的工作，简化了编写Java程序的任务，同时避免了常见情况下的转义序列。
• 增强表示非Java语言编写的代码的Java程序中字符串的可读性。
• 通过规定任何新构造都可以表示与字符串文字相同的字符串集，并解释相同的转义序列，并像字符串文字一样进行操作，来支持从字符串文字的迁移。

非目标：

• 为任何新构造表示的字符串定义不同于java.lang.String的新引用类型不是目标。
• 定义不同于+采用String操作数的新运算符不是目标。
• 文本块不直接支持字符串插值。 将来的JEP中可能会考虑内插。

拟定目标

简介：用一个更易于维护和调试的更简单，更现代的实现替换java.net.Socket和java.net.ServerSocket API使用的基础实现。 新的实现将很容易适应与用户模式线程（也称为光纤）一起使用，而Project Loom目前正在研究这种模式。

更新2019年5月9日

上次更新此帖子时，我们提出了两个针对JDK 13的JEP。

今天，ZGC：未提交的未使用内存和动态CDS存档JEP都针对JDK。 事情发展很快，对吗？

让我们刷新一下那些JEP的含义。

针对JDK 13

简介：扩展应用程序类数据共享，以允许在Java应用程序执行结束时动态归档类。 存档的类将包括默认基层CDS存档中不存在的所有已加载应用程序类和库类。

动机：相对于默认的CDS存档，在HotSpot中使用AppCDS归档应用程序类可提供额外的启动时间和内存好处。 但是，当前，需要三步过程才能将AppCDS用于Java应用程序。 在这里查看详细信息。

目标：

• 提高应用程序类数据共享（AppCDS）的可用性。 消除了用户进行试运行以为每个应用程序创建类列表的需求。
• 使用类列表，由-Xshare:dump选项启用的静态归档应继续工作。 这包括内置类加载器和用户定义的类加载器的类。

非目标：

• 仅归档在应用程序执行期间加载的类。 给定的JAR文件中存在但在执行过程中未加载的类将不会被归档。
• 在应用程序执行期间创建的Java堆对象将不会动态归档。
• 如果应用程序突然退出（例如，崩溃），将无法进行动态归档。

摘要：增强ZGC可以将未使用的堆内存返回给操作系统。

动机：即使长时间未使用该内存，ZGC当前也不会取消提交并将其返回给操作系统。 对于所有类型的应用程序和环境，尤其是那些关注内存占用的应用程序和环境，此行为都不是最佳的。

更新2019年4月26日

自上次更新此线程以来已经有一段时间了，但是今天我们回来了一些有趣的消息！

我们到达了开发下一个Java版本的下一步，我们看到针对JDK 13提出了前两个JEP。最重要的是，在JEP之后，我们有两个新的JEP候选对象，其中第二个是“ Switch Expressions”。 325：开关表达式（预览）已包含在最新的Java版本中。

我们来看一下。

拟定目标

摘要：增强ZGC可以将未使用的堆内存返回给操作系统。

简介：扩展应用程序类数据共享，以允许在Java应用程序执行结束时动态归档类。 存档的类将包括默认基层CDS存档中不存在的所有已加载应用程序类和库类。

JEP候选人

简介：与JEP 325有关：切换表达式（预览） –扩展switch语句，使其既可以用作语句也可以为表达式，并且两种形式都可以使用传统的作用域和控制流或新的，简化的范围和控制流，其中包括用于从switch表达式产生值的新语句。

简介：用一个更易于维护和调试的更简单，更现代的实现替换java.net.Socket和java.net.ServerSocket API使用的基础实现。 新的实现将很容易适应与用户模式线程（也就是光纤）一起使用，当前正在Project Loom中进行探索。

更新2019年4月1日

几周前，Mark Reinhold在邮件列表中添加了JDK 13的建议计划 。

由于没有人反对，因此Java 13的最终时间表如下所示：

更新2019年3月29日

一个多星期前，我们欢迎使用最新的Java版本。

但是，即使JDK 12刚刚到货，我们也已经在探索JDK未来版本的选择！

今天，我们欢迎候选人名单中的新JEP。

• JEP 352： 非易失性映射字节缓冲区

简介：增强了java.nio.MappedByteBuffer类，以便可以将实例映射到非易失性内存，并通过有效的高速缓存行刷新提交写入。

目标：该提案的主要目标是扩展MappedByteBuffer的公共API，以便可以将其用于从Java程序高效访问和更新NVM。

非目标：此JEP的目标并不超出为NVM提供访问权限和持久性保证。 特别地，该JEP的目标不是迎合其他重要行为，例如NVM的原子更新，读取器和写入器的隔离或独立持久存储状态的一致性。

更新2019年3月15日

距JDK 12的一般可用性仅几天之遥，我们已经在向前迈进！

今天，我们来看看JEP候选列表中又一个新增功能，以供将来使用JDK！

• JEP 351： ZGC ： 取消提交未使用的内存

摘要：增强ZGC可以将未使用的堆内存返回给操作系统。

动机：即使长时间未使用该内存，ZGC当前也不会取消提交并将其返回给操作系统。 对于所有类型的应用程序和环境，尤其是那些关注内存占用的应用程序和环境，此行为都不是最佳的。 HotSpot中的其他垃圾收集器（例如G1和Shenandoah）今天提供了此功能，某些类别的用户发现它非常有用。 同一组用户将欢迎将此功能添加到ZGC。

更新2019年3月4日

我们越来越接近JDK12的一般可用性-仅剩几周了！

但是没有时间放松，因为我们还有JEP 13的另一个JEP候选人。

我们来看一下。

• JEP 350： 动态CDS存档

简介：扩展应用程序类数据共享，以允许在Java应用程序执行结束时动态归档类。 存档的类将包括默认基层CDS存档中不存在的所有已加载应用程序类和库类。

目标

• 提高应用程序类数据共享（AppCDS）的可用性。 消除了用户进行试运行以为每个应用程序创建类列表的需求。
• 使用类列表，由-Xshare:dump选项启用的静态归档应继续工作。 这包括内置类加载器和用户定义的类加载器的类。

非目标

• 仅归档在应用程序执行期间加载的类。 给定的JAR文件中存在但在执行过程中未加载的类将不会被归档。
• 在应用程序执行期间创建的Java堆对象将不会动态归档。
• 如果应用程序突然退出（例如，崩溃），将无法进行动态归档。

更新2019年2月18日

我们距离Java 12的普遍可用性只有一个月的时间，但是已经是前进的时候了！

在发布JDK 13之前，我们还有很长的路要走，但就目前而言，让我们集中精力研究目前为止。 候选人名单越来越长； 例如，JEP 349已加入该党。

• 349： JFR事件流

摘要：公开JDK Flight Recorder数据以进行连续监视。

目标

• 提供一个API，用于在进程内和进程外应用程序中连续使用磁盘上的JFR数据。
• 记录与non-streaming.case相同的事件集，如果可能，开销小于1％。
• 事件流必须能够与基于磁盘和内存的非流记录共存。

非目标

• 为使用者提供同步回调。
• 允许使用内存中的记录。

风险和假设：

• API回调中的操作可能会引发JFR事件，这可能导致无限递归。 通过在这种情况下不记录事件可以缓解这种情况。

更新2019年2月4日

科技界的事物正以光速前进，JDK也是如此！ JDK 12仅仅在几周前就进入了Rampdown第二阶段 ，但是随着针对JDK 13提议并跟踪的针对漏洞修复，小增强功能和JEP的开发存储库的开发，该工作已经取得了进展。

最重要的是，我们引入了一个新的JEP候选人，因此现在是时候换一个新线程！

在发布JDK的下一个版本之前，我们还有很长的路要走，但就目前而言，让我们专注于目前为止。

JEP候选人

• 348： 用于JDK API的Java编译器内在函数

简介：使Java编译器能够使用替代转换策略，例如invokedynamic ，以提高某些被指定为编译器固有候选者的 JDK方法的性能。 具体来说，应激发String::format和Objects::hash的调用。

目标：使JDK开发人员能够（i）将方法标记为编译时内在化的候选者，并且（ii）描述符合候选方法规范的内在化候选者的适当替代翻译。

非目标：将内在化机制公开用于JDK库之外不是目标。

风险和假设：如果未正确实施，则替代翻译在行为上可能与规范或原始实施不完全兼容。 即使正确实施，替代实施也可能无法正确跟踪将来对原始实施所做的更改。 同样，即使适当地实现和跟踪，维护内在候选方法及其备用转换也变得更加困难，因为可能需要在两个地方进行更改并且行为必须相同。

确保遵循此线程以跟上Java世界中发生的所有新变化！

翻译自: https://jaxenter.com/keeping-track-of-jdk-13-155201.html

jdk1.8新特性::