java jdk12_JDK 12 beta：Java 12的新功能

java jdk12

Java Development Kit 12（Java SE的下一个版本）已经冻结了其主要功能集。 但是JDK 12中关于原始字符串文字的一项现有建议可以在本周的发布中删除。

计划中的Java升级将于2019年3月19日正式发布，预计于一个月前发布候选版本。 Oracle可以为Linux，Windows和MacOS提供JDK 12的Beta版。

[ Java JDK 11中所有重要的新功能 。 • 15个Java框架，可为开发人员提供帮助 。 | 通过InfoWorld的App Dev Report新闻通讯了解编程方面的热门话题。 ]

哪里可以下载测试版JDK 12版本

您可以从Java.net网站下载beta版JDK 12版本 。

旨在收集反馈的开源版本可能具有不包含在2019年3月19日发布的正式版中的功能。它们也可能缺少安全漏洞修复程序，并且不受Oracle支持。

Java 12中计划的新功能

雪兰多亚垃圾收集器

该提议要求添加一个实验性垃圾收集算法Shenandoah，以通过在运行Java线程的同时执行疏散工作来减少垃圾收集暂停时间。 Shenandoah为重视响应能力和可预测的短暂停顿的应用程序提供了合适的算法。 但是，其目的不是解决所有JVM暂停问题。

红帽公司目前在Aarch64和AMD64架构上支持Shenandoah。

G1垃圾收集器的可中止混合收集

如果G1混合集合可能超出暂停目标，则该提议将使其中止。 G1的目标是达到用户为其收集暂停提供的暂停时间目标。

当前，高级分析引擎选择收集期间要完成的工作量。 结果是一组区域，称为集合集。 确定集合并开始收集后，G1必须不间断地收集所有区域中所有区域中的所有活动对象。 但是，如果应用程序的启发式方法选择的集合集太大，则可能导致G1超过暂停时间目标。

需要一种机制来检测启发式方法何时为集合重复选择了不正确的工作量，并且如果发生这种情况，则让G1分步逐步执行收集工作，在此之后每个步骤都可以中止收集。 提出的机制将使G1更频繁地满足暂停时间目标。

Swift返回未使用的已提交内存

根据该建议，将增强G1以在空闲时自动将Java堆内存返回到操作系统。 当应用程序活动非常少时，将在合理的时间内释放此内存。

G1当前不执行此操作。 仅在完整的垃圾回收或并发周期中才从堆返回内存。 在G1试图避免完全垃圾回收的情况下，仅根据堆占用和分配活动触发并发周期，在许多情况下，除非被迫在外部这样做，否则它不会返回堆内存。 在通过使用付费资源的容器环境中，此行为是不利的。 即使当VM由于不活动而仅使用其分配的内存的一小部分时，G1也会保留整个堆。 因此，客户一直在为所有资源付费，而云提供商则无法完全使用其硬件。

如果VM能够检测到堆未充分利用的阶段并在此期间自动减少其堆使用情况，那将是有益的。 该提案试图这样做。

JVM常数API

该API将对密钥类文件和运行时工件的名义描述进行建模，尤其是可从常量池加载的常量。 该提案在新包java.lang.invoke.constant定义了一系列基于值的符号引用类型，以描述每种可加载常量。

常量池存在于每个Java类中，并在该类中存储操作数和字节码指令。 常量池中的条目描述了运行时工件（例如类和方法）或简单值（例如字符串和整数）。 这些条目称为可加载常量。

操纵类文件的程序必须对字节码指令进行建模，然后对可加载常量进行建模。 但是，使用标准Java类型对可加载常量进行建模是不够的。 对于描述字符串的可加载常量，这可能是可以接受的，但对于描述类的可加载常量，这是有问题的，因为生成“活动的” Class对象依赖于类加载的正确性和一致性。 但是，类加载具有许多环境依赖性和故障模式。

因此，处理可加载常量的程序如果可以操纵类和方法以及鲜为人知的工件（如方法句柄和名义上象征性的形式的动态计算的常量），则将更加简单。 库和工具将受益于描述可加载常量的单一标准方法，这是这里的目标。

改进了启动，CDS和垃圾收集

计划要求增强JDK构建过程，以在64位平台上使用默认类列表生成默认类数据共享（CDS）存档。 目标是包括开箱即用的启动时间， -Xshare:dump需要运行-Xshare:dump来从CDS中受益。 计划要求在链接映像后修改JDK构建以运行java-xshare:dump 。

可能包括其他命令行选项，以微调垃圾回收堆时间，以改善常见情况下的内存布局。 具有更高级要求的用户，例如包含应用程序类和不同垃圾收集配置的自定义类列表，仍将能够创建自定义CDS存档。

减少了ARM端口数量

Java 12将只有一个端口，而对于ARM处理器则只有两个。 计划是在保留32位ARM和64位aarch64同时删除所有与arm64端口相关的源。 删除此端口将使贡献者将精力放在单个64位ARM实施上，并消除维护两个端口可能导致的重复工作。 当前，JDK中有两个64位ARM端口。

切换表达式

Beta开关表达式功能可以通过扩展switch语句来简化编码，因此它既可以用作语句也可以用作表达式。 这将使两种形式都可以使用“传统的”或“简化的”作用域并控制流的行为。 这些更改将导致简化的“日常”编码，并为在switch使用模式匹配提供了方法。

随着Java构建者开始支持模式匹配，现有switch语句的现有不规则性成为了障碍。 这些包括开关块的默认控制流行为； 切换块的默认作用域，其中该块被视为一个单一作用域； 并仅以声明的方式进行切换。 Java的switch语句的当前设计紧密遵循诸如C ++之类的语言，并且默认情况下支持fallthrough语义。 此控制流对于编写低级代码很有用。 但是，由于在较高级别的上下文中使用了switch，因此它易于出错的性质开始超过了灵活性。

原始字符串文字

Beta原始字符串文字将跨越源代码的多行，而不会解释/uXXX格式的转义序列，例如\n或Unicode转义。 Java的构建器对此功能有多个目标，包括：

• 使Java更加容易以可读的形式表示字符序列，而无需Java即可简化提供Java以外的语法目标字符串的过程。
• 提供跨越源代码几行的字符串，而没有用于新行的特殊指示符。
• 表示与传统字符串文字相同的字符串的能力，平台特定的行终止符除外。
• 库支持复制当前的javac字符串文字转义解释，并管理左边界修整。

Java 12的开发人员说，现实世界中的Java代码需要一种可以照原样捕获文字字符串的机制，而无需对Unicode转义，反斜杠或换行进行特殊处理。 原始字符串文字保留了Java转义符和Java行终止符规范，提供了在许多情况下比现有字符串文字更具可读性和可维护性的字符序列。

Java仍然是少数没有语言级别的原始字符串支持的语言之一。 该提案将不会引入任何新的字符串运算符。 同样，原始字符串文字也不直接支持字符串插值。 传统字符串的内插不会有任何变化。

基本基准套件

Java开发工具包（JDK）12预计将包含基本的基准测试套件，该基准套件将添加到平台的源代码中。 目的是使开发人员更容易运行现有基准或建立新基准。

Microbenchmarks套件提案于2014年7月创建，并于2018年11月初进行了更新，由Java Microbenchmark Harness（JMH）支持，用于构建用Java和其他JVM语言编写的基准。 该套件将与JDK源代码并置在一个目录中，从而使开发人员能够轻松添加新基准。

为新的JDK功能提供基准或创建涵盖JDK中所有内容的完整基准不是目标。

该计划存在风险，例如，显着增加了构建时间，新基准中潜在的测试不稳定以及增加了源代码存储库的大小。 但是，常规JDK构建不需要基准测试套件，它将成为一个单独的构建目标。 为了解决潜在的测试不稳定问题，将需要对新基准进行全面测试。

该提案要求在wiki.openjdk.java.net上创建一个新页面，以解释如何开发基准和描述需求。 这些要求将要求遵守编码标准，可复制的性能和文档。

翻译自: https://www.infoworld.com/article/3301461/jdk-12-roadmap-java-12-gets-first-targeted-feature.html

java jdk12