非开发人员功能
JEP 181：基于嵌套的访问控制
Java（和其他语言）通过内部类支持嵌套类。为了使其正常工作，它需要编译器执行一些技巧。这是一个例子：
public class Outer {
private int outerInt;
class Inner {
public void printOuterInt() {
System.out.println("Outer int = " + outerInt);
}
}
}在执行编译之前，编译器会修改它以创建类似的东西：
public class Outer {
private int outerInt;
public int access$000() {
return outerInt;
}
}
class Inner$Outer {
Outer outer;
public void printOuterInt() {
System.out.println("Outer int = " + outer.access$000());
}
}虽然从逻辑上讲，内部类是与外部类相同的代码实体的一部分，但它被编译为一个单独的类。因此，它需要编译器创建合成桥接方法，以提供对外部类的私有字段的访问。
这个JEP引入了巢的概念，其中同一巢的两个成员（我们的例子中的外部和内部）是同窝。两个新的属性的类文件格式定义， NestHost 和 NestMembers。这些更改对于支持嵌套类并编译为字节码的其他语言非常有用。
此功能引入了三种新方法 java.lang.Class：
-
getNestHost() -
getNestMembers() - 布尔
isNestmateOf(Class)
此功能还需要更改Java虚拟机规范（JVMS），特别是第5.4.4节“访问控制”。
JEP 309：动态类文件常量
此JEP描述了类文件格式的扩展，以支持新的常量池形式 CONSTANT_Dynamic （在演示文稿中通常称为“condy”）。动态常量的想法似乎是矛盾的，但实际上，你可以把它看作Java中的最终值。常量池值不在编译时设置（与其他常量不同），但使用引导方法在运行时确定值。因此，该值是动态的，但由于其值仅设置一次，因此它也是常量。
此功能主要针对开发新语言和编译器的人员，这些语言和编译器将生成字节码和类文件作为要在JVM上运行的输出。它简化了为此所需的一些任务。
此功能引入了一个新类 java.lang.invoke.ConstantBootstraps，有九种新方法。我不会在这里列出所有这些; 这些是动态计算常量的引导方法。
此功能需要更改JVMS，特别是在 invokespecial 字节码的使用方式和第4.4节“常量池”中。
JEP 315：改进Aarch64内在函数
这是由Red Hat贡献的JEP。JVM现在能够利用Arm 64指令集中提供的更多专用指令。具体而言，这提高了性能 sin()， cos()和 log() 方法 java.lang.Math class。
JEP 318：Epsilon垃圾收集器
红帽也贡献了这个JEP。Epsilon收集器有点不寻常，因为它不会收集任何垃圾！它将在实例化新对象时根据需要分配内存，但不会回收未引用对象占用的任何空间。
当你第一次看到这个时，你认为那是什么意思？事实证明，有两个用途：
- 该收集器主要用于对新GC算法的性能影响进行评估。我们的想法是使用Epsilon GC运行示例应用程序并生成一组指标。打开新的GC算法，运行相同的测试并比较度量结果。
- 对于非常短暂的任务（在云中思考无服务器功能），您可以保证不会超过分配给堆的内存，这可以通过不产生任何开销来提高性能（包括收集必要的统计信息以决定何时运行应用程序代码上的收集器）。
如果堆空间耗尽，可以通过以下三种方式之一将JVM配置为失败：
- 传统
OutOfMemoryError的抛出。 - 执行堆转储
- 使JVM失败并可选择执行其他任务（如运行调试器）。
JEP 324：与Curve25519和Curve448的关键协议
加密标准不断变化和改进。在这种情况下，现有的椭圆曲线Diffie-Hellman方案正在被Curve25519和Curve448取代。这是RFC-7748定义的密钥协商方案。
JEP 327：Unicode 10
Java平台支持Unicode以允许处理所有字符集。由于Unicode已更新到版本10，因此JDK也已更新为支持此标准的修订版。
我总是很想知道Unicode维护者在新版本中包含的内容。Unicode 10有8,518个新符号。这包括比特币符号，Nüshu字符集（中国女性用于写诗），以及Soyombo和Zanabazar Square（在历史佛教文本中用来写梵语，藏语和蒙古语的字符）。还有更多的表情符号，包括期待已久的（显然）科尔伯特表情符号。
请记住，从JDK 9开始，您可以在属性文件中使用UTF-8。这意味着任何Unicode字符都可以在属性文件中使用，包括emojis或Nüshu。
JEP 328：飞行记录器
Flight Recorder是JVM的低开销数据收集框架。在JDK 11之前，这是Oracle JDK二进制文件中的商业功能。既然Oracle正在消除Oracle JDK与OpenJDK源代码之间的功能差异，那么这个功能已经被OpenJDK所贡献。
这有四个部分：
- 提供用于生成和使用数据作为事件的API
- 提供缓冲机制和二进制数据格式
- 允许配置和过滤事件
- 为OS，HotSpot JVM和JDK库提供事件
这有两个新模块： jdk.jfr 和 jdk.management.jfr。
JEP 329：ChaCha20和Poly1305加密算法
与JEP 324类似，这是对JDK使用的密码的更新。在这种情况下，实现RFC 7539中指定的ChaCha20和ChaCha20-Poly1305密码.ChaCha20是一种相对较新的流密码，可以替代旧的，不安全的RC4流密码。
JEP 331：低开销堆分析
有点令人惊讶的是，这是由Google提供的JEP。这提供了一种从JVM获取有关Java对象堆分配的信息的方法：
- 低开销足以在默认情况下连续启用
- 可通过定义明确的编程接口访问
- 可以对所有分配进行采样
- 可以以与实现无关的方式定义（即，不限于特定的GC算法或VM实现）
- 可以提供有关实时和死Java对象的信息。
JEP 332：传输层安全性（TLS）1.3
TLS 1.3（RFC 8446）是TLS协议的重大改进，与以前的版本相比，它提供了显着的安全性和性能改进。JDK现在支持这一点，但这并未扩展到数据报传输层安全性（DTLS）。
JEP 333：ZGC是一个可扩展的低延迟垃圾收集器
这是一个新的实验性垃圾收集器，设计用于需要大（几千兆字节）堆和低延迟的应用程序。它使用单代堆（由于弱代传统假设的公认智慧，这有点不寻常）并且与应用程序同时执行大部分（但不是全部）GC工作。它通过使用读取屏障来执行此操作，该读取屏障截取应用程序中对象的每个读取并确保返回的引用是正确的。这消除了在应用程序线程运行时能够并发地重定位对象的问题。
ZGC是基于区域的（如G1），NUMA识别和压缩。它不是一个通用的收集器。
如果你想要一个低延迟的真正无间断收集器，我可以在我们的Zing JVM中衷心推荐C4。
JEP 335：弃用Nashorn脚本引擎
Nashorn在JDK 8中被引入作为Rhino Javascript引擎的更高性能替代品。目的是从未来的Java版本中删除Nashorn以及相关的API和jjs工具。当这种情况发生时还没有决定。已经建议使用Graal VM作为替代品的可能性，但是尚未评估其如何工作。
JEP 336：弃用Pack200工具和API
Pack200是Java SE 5.0中引入的JAR文件的压缩方案。随着JDK 9中JPMS的引入，Pack200不再用于压缩JDK本身。pack200，unpack200工具和Pack200 API java.util.jar 现已弃用，可能会在将来的JDK版本中删除。何时发生这种情况尚未明确。
结论
JDK 11是JDK的下一个LTS版本（由Oracle定义，其他人都遵循）。虽然没有很多以开发人员为中心的功能，但是JVM中有很多功能正在下降，为未来更突出的功能奠定了基础。
https://www.leftso.com/article/522.html
相关文章
