JDK11介绍
JDK 11 特性
做为java开发JDK的更新内容是必须要关注的,这里我把JDK11的相关的JEP(JDK Enhancement Proposals),汇总并偿试了一下。
分享一下相关的改进点。
历史所有JEP:http://openjdk.java.net/jeps/0
JDK11发版 JEP 汇总
JDK11 于2018年9月25日发布正式版,其中官方给出的改进JEP如下:
JEP-181 嵌套类可见性控制
JEP-309 动态类文件常量
JEP-315 改进 Aarch64 Intrinsics
JEP-318 Epsilon–一个无操作的垃圾收集器
JEP-320 删除 Java EE 和 CORBA 模块
JEP-321 HttpClient
JEP-323 用于 Lambda 参数的局部变量语法
JEP-324 Curve25519 和 Curve448 算法的密钥协议
JEP-327 Unicode 10
JEP-328 Flight Recorder(飞行记录器)
JEP-329 haCha20 和 Poly1305 加密算法支持
JEP-330 Launch Single-File Source-Code Programs(启动单一文件的源代码程序)
JEP-331 低开销的 Heap Profiling
JEP-332 TLS 1.3支持
JEP-333 ZGC: A Scalable Low-Latency Garbage Collector(可伸缩低延迟垃圾收集器)
JEP-335 弃用 Nashorn JavaScript 引擎
JEP-336 弃用 Pack200 工具和 API
有些泛及底层有些泛及开发的方方面面,后面对这些特性进行逐说明,以及使用JDK11开发我们需要注意的事项。
JEP-181 嵌套类可见性控制
这一提案是为了增强自Java 1.1即引入的嵌套类设计。
嵌套类主要有两个用处。
第一是因为其只使用于很短的代码块中,在Java8之前,这主要依靠实现一个匿名类来完成。Java8之后,这种用法可以被lambda表达取代。
另一种用法是因为需要访问另一个类的内部。嵌套类具有和成员变量以及成员方法相同的访问权限。
JEP181主要是为了解决JVM级别的权限与源码权限不一致的问题。
1 | public class JEP181 { |
运行结果
java11: 2
Java8:
Exception in thread "main" java.lang.IllegalAccessException: Class JEP181$Nest1 can not access a member of class JEP181$Nest2 with modifiers "private"
主要问题出在f2.setInt(nest2,2)
,这里由于在Nest2
中是private的,所以无法直接set值。但是却又可以直接调用nest2.var2=2
来设置该值,因为嵌套类是可以访问别的嵌套类的私有属性的。Java 11修复了这个令人困惑的现象。
JEP-309 动态文件常量
这其实是一个联动一个比较早的改近。Java SE 7 已将 invokedynamic 引入了其指令集。Java 开发人员通常不会注意到此功能,它隐藏在 Java 字节码中。
Java的类型文件格式将被拓展,支持一种新的常量池格式:CONSTANT_Dynamic,加载CONSTANT_Dynamic会将创建委托给bootstrap方法。
目标: 其目标是降低开发新形式的可实现类文件约束带来的成本和干扰。
JEP-315 改进 Aarch64 Intrinsics
优化了现有的字符串和数组内部函数,并在Arm64或Aarch64处理器上为Math.sin() ,**Math.cos()和Match.log()**实现了新的内部函数。这意味着更好的性能。
内部函数用于利用特定于CPU体系结构的汇编代码来提高性能。
JEP-318 Epsilon–一个无操作的垃圾收集器
开发一个处理内存分配但不实现任何实际内存回收机制的 GC。 一旦可用的 Java 堆耗尽,JVM 将关闭。
它为以下内容分配内存:
性能测试。
内存压力测试。
VM 接口测试。
寿命极短的工作。
最后一滴延迟改进。(Last-drop latency improvements.)
最终吞吐量提高。
现在,Elipson 仅适用于测试环境。这将导致生产中的 OutOfMemoryError 并使应用程序崩溃。
Elipson 的好处是没有内存清除开销。因此,它将给出准确的性能测试结果,我们不再可以通过 GC 来停止它。
注意:这是一项实验性功能。
JEP-320 删除 Java EE 和 CORBA 模块
Java 9 中已经弃用了这些模块,现在将它们完全删除。
这个的话,主要还是Spring 的原因。JavaEE 比较重,开发配置特别繁锁,Spring的轻量化是事实的标准,更加简单的使用,导致像 EJB 这种重型框架没有市场,删除是必然的。
下面的包被删除:
java.xml.ws,java.xml.bind,java.activation,java.xml.ws.annotation,java.corba,java.transaction,java.se.ee,jdk.xml.ws,jdk.xml.bind
JEP 321 HttpClient
Java 11 标准化了 Http CLient API。其实就是重写了 HttpClient 内部逻辑 ,接口没变。
目前版本已经支持HTTP1.1、HTTP2、websocket等常用的基于http的协议,并支持了了同步、异步、响应式等交互方式。当前版本的实现还是比较简单,没有对于常用restful、content-type的封装支持。
JEP-323 用于 Lambda 参数的局部变量语法
这个算是一堆 JEP 中唯一在语法特性的改进。
Java 10 中引入了局部变量类型推断 var,示例:
1 | var list = new ArrayList<String>(); |
java10中需要显示的声明 var 在 lambda 中的定义
1 | List<String> list = Arrays.asList("嗯哼", "啊哈", "哦吼"); |
JEP 323 允许 var
用于声明隐式类型的 Lambda 表达式的形式参数,Java8 中也是允许在,只是在Java10中删除了这个特性,Java11中又把这个特性拿回来了:
1 | List<String> list = Arrays.asList("嗯哼", "啊哈", "哦吼"); |
JEP-324 Curve25519 和 Curve448 算法的密钥协议
密码学相关项目,它将现有的椭圆曲线Diffie-Hellman(ECDH)方案替换为Curve25519和Curve448算法,这是RFC 7748中定义的关键协议方案。
GenerateKeyPairs.java
1 | package com.mkyong.java11.jep324; |
结果:
1 | --- Public Key --- |
进一步阅读
有关更多示例,请参考JEP 324和Oracle – Java安全标准算法名称。
JEP-327 Unicode 10
Unicode 10.0增加了8,518个字符,总共136,690个字符。这些增加包括4个新脚本,总共139个脚本,以及56个新表情符号字符。
看看效果:
1 | public class PrintUnicode { |
结果:
🤪
JEP-328 Flight Recorder(飞行记录器)
Flight Recorder 以前是 Oracle JDK 中的商业附加组件,现已开放源代码。
JFR 是一种分析工具,用于从正在运行的 Java 应用程序中收集诊断信息和分析数据。它的性能开销可以忽略不计,通常低于 1%。因此,它可以用于生产应用。
默认情况下,JVM 禁用了 JFR,要启动 JFR,必须使用 -XX:+FlightRecorder 选项启动。例如,我们要启动名为 MyApp 的应用程序:
1 | java -XX:+ UnlockCommercialFeatures -XX:+ FlightRecorder MyApp |
JEP-329 chaCha20 和 Poly1305 加密算法支持
Java 11 提供了 ChaCha20 和 ChaCha20-Poly1305 密码实现。这些算法将在 SunJCE 提供程序中实现。
实现 RFC 7539 中指定的 ChaCha20 和 ChaCha20-Poly1305 密码。ChaCha20 是一种相对较新的流密码,可以替代旧的、不安全的 RC4 流密码。
chacha20-Poly1305是Google所采用的一种新式加密算法,性能强大,在CPU为的ARM平台上尤为显著(ARM v8前效果较明显),在同等配置的手机中表现是AES的4倍(ARM v8之后加入了AES指令,所以在这些平台上的设备,AES方式反而比chacha20-Poly1305方式更快,性能更好),可减少加密解密所产生的数据量进而可以改善用户体验,减少等待时间,节省电池寿命等。
JPE330 启动单一文件的源代码程序
这个功能初学阶比较有用,不必再关心先java
再 javac
这样的两步操作:
1 | public class HelloWorld { |
直接运行:
Java HelloWorld.java
JEP-331 低开销的 Heap Profiling
Java 虚拟机工具接口(JVM TI)是在 Java SE 5 引入的,它可以监控 JVM 内部事件的执行,也可以控制 JVM 的某些行为,可以实现调试、监控、线程分析、覆盖率分析工具等。
该 JEP 在 JVM TI 中添加了新的低开销的堆分析 API。
JEP-332 TLS 1.3支持
TLS: 传输层安全性
Java 11 支持 RFC 8446 传输层安全性(TLS)1.3协议。但是,并非所有TLS 1.3功能都已实现,有关详细信息。
Java 安全套接字扩展(JSSE)+ TLS 1.3 示例:
1 | import javax.net.ssl.SSLSocket; |
JEP 335: 弃用 Nashorn JavaScript 引擎
Nashorn JavaScript脚本引擎和jjs
工具已被弃用,将来的发行版中可能会删除它。
ECMAScript的语言结构变化太快,Oracle发现,维护Nashorn JavaScript引擎变得非常困难。
Nashorn最初是在JDK 8(JEP174中引入)中引入的,用于取代Rhino脚本引擎(java1.6引入的脚本引擎)。当其发布时,Nashorn是ECMAScript-262 5.1的完整实现,增强了Java和JavaScript的兼容性。最近还增加了新的ECMAScript 6(ES6)特性。借助Nashorn,开发人员可以从JavaScript调用Java代码,也可以从Java代码调用JavaScript函数。Nashorn可以作为Java应用程序的嵌入式解释器,提供使用Nashorn命令行工具jjs从命令行运行JavaScript的能力。
JEP 336: 弃用 Pack200、unpack200 工具和 API
不推荐 pack200 和 unpack200 工具以及软件包中的 Pack200 API java.util.jar,并且可能会在将来的版本中删除。
Java 14 JEP 367 中删除了 Pack200 工具和 API 。
Pack200,这个工具能对普通的jar文件进行高效压缩。其实现原理是根据Java类特有的结构,合并常数池,去掉无用信息等来实现对java类的高效压缩。
由于是专门对Java类进行压缩的,所以对普通文件的压缩和普通压缩软件没有什么两样,但是对于Jar 文件却能轻易达到10-40%的压缩率。
这在Java应用部署中很有用,尤其对于移动Java计算,能够大大减小代码下载量。
废弃的原因:
- Java 9 中引入了新的压缩方案 JMOD
- Pack200 本身复杂,维护复杂
总结
大至上就是这么多了,小伙伴们可以自行动手玩一把。