发布倒计时！JDK11为我们带来哪些新特性?

Posted 2020-12-27 lkxsnow

　　今年7月底，JDK11已经进入了Rampdown Phase Two阶段，这标志着该版本所有特性已经被冻结，不会有新的JEP会加入版本中。

　　这一阶段将会修复P1–P2级BUG,之后,JDK11预定于今年9月25日发布。确定发布的17个JEP如下,其中包括14个新特性以及3个移除的功能：

　　181: Nest-Based Access Control（基于嵌套的访问控制）
　　309: Dynamic Class-File Constants（动态类文件常量）
　　315: Improve Aarch64 Intrinsics（改进 Aarch64 Intrinsics）
　　318: Epsilon: A No-Op Garbage Collector（Epsilon — 一个无操作的垃圾收集器）

　　321: HTTP Client (Standard)（标准HTTP客户端）

　　323: Local-Variable Syntax for Lambda Parameters（用于 Lambda 参数的局部变量语法）

　　jdk10中带来了var隐式变量声明，如：

var x = new Foo();
for (var x : xs) { ... }
try (var x = ...) { ... } catch ...

　　jdk11中将允许在声明隐式类型的 lambda 表达式的形式参数时使用 var，如：

(var x, var y) -> x.process(y)

　　或者干脆省略掉var符号

(x, y) -> x.process(y)

324: Key Agreement with Curve25519 and Curve448（Curve25519 和 Curve448 算法的密钥协议）
327: Unicode 10
328: Flight Recorder（飞行记录器）

　　"飞行记录器"旨在“提供一个低开销的数据收集框架，用于对Java应用程序和HotSpot JVM进行故障诊断”。

329: ChaCha20 and Poly1305 
Cryptographic Algorithms（ChaCha20 和 Poly1305 加密算法）
330: Launch Single-File Source-Code Programs（启动单一文件的源代码程序）

　　主要是改进 Java Launcher 以支持一个命令执行单个 Java 源代码文件。换句话说，在条件满足的情况下，可以简单地直接编译并运行单文件程序，而不再需要调用 javac ，也不需要打包 jar 文件。

　　比如说，可直接运行：

java HelloWorld.java

而不再需要：

javac -d <memory> HelloWorld.java
java -cp <memory> hello.World

 

331: Low-Overhead Heap Profiling（低开销的 Heap Profiling）
332: Transport Layer Security (TLS) 1.3（支持 TLS 1.3）
333: ZGC: A Scalable Low-Latency Garbage Collector（可伸缩低延迟垃圾收集器）

　　上一代的垃圾回收器G1已经足够强大，但是，ZGC可能会更加惊艳，ZGC的一个目标是将垃圾回收的暂停时间压缩到10ms之内，这意味着Java可以成为应用到更广泛的领域。官方文档提供了ZGC与G1的benchmarks测试对比，我们看到对比G1的156.806ms平均时间，ZGC的垃圾收集时间低至1.091ms

ZGC
                avg: 1.091ms (+/-0.215ms)
    95th percentile: 1.380ms
    99th percentile: 1.512ms
  99.9th percentile: 1.663ms
 99.99th percentile: 1.681ms
                max: 1.681ms

G1
                avg: 156.806ms (+/-71.126ms)
    95th percentile: 316.672ms
    99th percentile: 428.095ms
  99.9th percentile: 543.846ms
 99.99th percentile: 543.846ms
                max: 543.846ms

 

320: Remove the Java EE and CORBA Modules（删除 Java EE 和 CORBA 模块）
335: Deprecate the Nashorn javascript Engine（弃用 Nashorn JavaScript 引擎）
336: Deprecate the Pack200 Tools and API（弃用 Pack200 工具和 API）

此外，还有一些除 JEP 之外的API变化,比较实用的有以下几个：

String

• lines()

　　字符串实例方法，使用专门的 Spliterator 来懒惰地提供源字符串中的行

jshell> "test
hoge
".lines().map(String::toUpperCase).toArray()
$11 ==> Object[2] { "TEST", "HOGE" }

• repeat(int)

　　按照参数 int 提供的次数来重复字符串的运行次数

jshell> "test".repeat(3) $7 ==> "testtesttest"

• isBlank()  

　　验证当前字符串是否为空，或者是否只包括空白字符（空白字符由 Character.isWhiteSpace(int) 验证）

jshell> var halfSpace = "u0020"
halfSpace ==> " "

jshell> halfSpace.isBlank()
$11 ==> true

jshell> var fullSpace = "u3000"
fullSpace ==> "　"

jshell> fullSpace.isBlank()
$13 ==> true

• strip()/stripLeading()/stripTrailing()

　　这三个方法的作用分别是去掉字符串头和尾的空白符、字符串头的空白符、字符串尾的空白符，基本与 trim()/trimLeft()/trimRight() 方法相同，不过它们的空白字符由 Character.isWhiteSpace(int) 验证

jshell> var aaa = fullSpace + "aaa" + fullSpace
aaa ==> "　aaa　"

jshell> aaa.strip()
$14 ==> "aaa"

jshell> aaa.trim()
$15 ==> "　aaa　"

Character

• toString(int)

　　JDK 11 使这个过程变得更加方便

jdk10：
jshell> Character.toString(65)
|  Error:
|  incompatible types: possible lossy conversion from int to char
|  Character.toString(65)
|

jdk11：
jshell> Character.toString(65)
$9 ==> "A"

Path

• of(String, String...)

　　此前我们需要使用 Paths.get()。现在，我们像其他类一样使用 of()。

Files

• writeString(Path, CharSequence)

　　我们可以使用该方法来保存一个 String 字符串。

jshell> Files.writeString(Path.of("test.txt"), "Hello!!!")
$3 ==> test.txt

• readString(Path)

　　我们可以使用该方法来读取一个 String 字符串。

jshell> Files.readString(Path.of("test.txt"))
$4 ==> "Hello!!!"

Collection

• toArray(IntFunction)

此前，我们需要使用像 list.toArray(new String[list.size())]) 这样的无风格标记(non-stylish notation)来从一个集合创建一个类型化数组。现在，我们可以以风格标记(stylish notation)的方式进行编写。

jshell> List.of("aa","bb").toArray(String[]::new) $1 ==> String[2] { "aa", "bb" }

Thread

• destroy()/stop(Throwable)

　　移除 destroy() 方法，保留 stop() 方法。

 

　　Java 9以来,oracle实行了半年一次版本的新计划，很多同学说 9未掌握10刚了解11已进冻结期，
　　你呢？

 

参考资料：
http://openjdk.java.net/projects/jdk/11/
https://www.oschina.net/news/98314/java-11-api-changes-so-far