掌握聚合最新动态了解行业最新趋势
API接口,开发服务,免费咨询服务

深入解读 Java 9 新特性

杨晓峰,OpenJDK Committer (JDK 9 和 JDK 10 项目),2011 年加入 Oracle 北京研发中心 Java 团队,目前领导 Java 核心类库北京团队,领导或参与了 Java 9,8 和 7 的核心类库等模块的新特性测试和开发工作。个人技术兴趣广泛,主要专注于 Java 等编程语言的发展,尤其是在云计算等前沿领域的应用和演进。

很高兴能有机会通过高可用架构社区和大家交流 Java 9 的主要新特性,由于内容较多,本文仅做一个概要性介绍,希望深入讨论某个方面的更多细节,可以在本文留言探讨。

今天的分享,除了简单介绍 Java 平台模块化项目(Jigsaw ),主要是如下四部分

  • Java 类库新特性,比如支持的新的标准、新的 API 等。

  • 语言和工具的变化。

  • JVM 领域新特性。

  • 简短介绍 Java 未来的发布模式。

基本上是按照目前 JDK 自身组成进行的划分。另外,在开始之前,介绍一个词汇JEP(JDK Enhancement Proposals),这是 Java 9 中 Oracle 为管理新特性引入的概念,后面谈到具体特性时大家会发现每一个都有相应的 JEP 号码。

首先,我们就来看看 Jigsaw 项目。

其核心是实现 Java 平台模块化系统(JSR 376,Java Platform Module System,经常会简化为JPMS),这是个庞大的项目,今天抛砖引玉简单介绍一下。

Mark Reinhold 曾经提到,Jigsaw 试图解决的是两个基础性的问题:

一 、脆弱的、容易出问题的 classpath:

Classpath 就是个非常简陋的容器,Jar 其实也不提供任何边界。所以,各部分的依赖关系是隐式的,或者说是隐晦的。在实际应用中,可能导致所谓的 Jar Hell 问题。例如有可能会出现,应用的不同部分依赖于同一类库的不同版本,进而导致类加载出现不可预计的行为。

ClassLoading 非常复杂,有些行为是不明确的。做过 Java EE 中间件的同学,可能都还记得,某些 Java EE 服务器以讨厌的 ClassNotFoundException、NoClassDefFoundError 之类问题而臭名昭著。

二、JDK 自身是一个大的单体应用,越来越臃肿。这是一个扩展性问题,JDK 自身很难按照不同需求进行定制或者优化,同时也会衍生出安全、维护等各种问题。

所以,Jigsaw 项目的目标,主要是两点:

  • 可靠的配置:明确模块边界和模块之间的依赖关系

  • 强封装性:通过封装模块内部私有细节,来避免不希望发生的依赖关系,也能避免一些安全问题等。

理论上,良好封装能让开发变得更敏捷,因为彼此之间的依赖、交互是明确的,可以鼓励基于契约的开发。

Jigsaw 项目主要被分解为六个JEP:

  • JEP 261: Module System,实现模块化系统;

  • JEP 200: The Modular JDK,将JDK自身进行模块化;

  • JEP 201: Modular Source Code,按照模块化的形式,重构源代码,因为现有代码并不是划分到一个一个的模块里的。

  • JEP 220: Modular Run-Time Images,重新设计JDK和JRE的结构,定义新的URI scheme操作模块,类和资源(jrt)。

  • JEP 260: Encapsulate Most Internal APIs,按照模块化封装性的要求,将不希望暴露的内部API封装起来,如果确实证明是广泛需要的,就作为公共API公开出来。

  • JEP 282: jlink: The Java Linker。新的link工具

从开发者的角度,代码和功能主要有下面这些变化:

  • 新增或修改工具和 API,用以在编译、链接和运行时支持模块。例如,基于 Module 的抽象,提供相应的 API 进行解析、配置或运行时操作等。

  • 工具方面,比如,最常用的 javac/java,增加了对模块的支持,支持 module path,另外还提供了各种针对模块的选择。

  • Java9 新增了一个可选的链接阶段(linking Phase),可以方便地创建最小依赖关系的 Java 运行时。

大家可以看看模块化以后的 Java SE:

未命名1509003147.png

“java.base”是最基础的模块,核心类库的代码大部分都在这个模块。其他模块,从名字就可以大概地看出具体是哪个方面的类库。需要提醒的是,模块也可能是聚合其他模块组成,本身可能并不包含任何源代码,如“java.se”就是这样的聚合模块。

大家可能好奇,怎么查看具体某个 Java 模块的细节呢?在 Javadoc 里面就有很清晰的模块图和具体内容,比如:

http://download.java.net/java/jdk9/docs/api/java.se-summary.html

Java 通常分为编译期或者运行时,在 Java 9 中,增加了可选的链接阶段(linking phase),可以用新增的 jlink 工具来定制运行时环境。完美地应用在实际应用场景,还需要更多大家的反馈和完善。

下面是一个例子

$ jlink --module-path jmods/ \

            --add-modules java.sql.rowset,java.activation \

            --output myimage

$ myimage/bin/java --list-modules

java.activation@9

java.base@9

java.datatransfer@9

java.logging@9

java.naming@9

java.security.sasl@9

java.sql@9

java.sql.rowset@9

java.xml@9

$ myimage/bin/java –m company.application

对于有 Java 使用经验的同学,这些都是非常容易理解的,可以很快上手。

第二,就是 Java 类库相关新特性。

我大致进行了分类,也主要关注在核心类库和安全类库方面:

  • 开发的工具API;

  • 新标准或者协议的支持;

  • 性能等方面的优化。 

首先,谈谈新的工具 API。

JEP 102:Process API Updates:

Java 历史版本以前对进程操作的支持是非常有限的,比如获取当前进程的 Pid 等信息,都往往要使用些 hack 手段。 在 Java9 里,新增了ProcessHandle 这种抽象,Process 也进行了相应扩展。开发者可以利用 ProcessHandle 访问 ProcessHandle.info 数据结构,来获取类似 pid、启动参数及累计的运行时间等信息。也可以更优雅的进行进程监控、销毁之类操作。例如利用 ProcessHandle.onExit 去在进程退出时做一些动作。

这是一段简单的例子:

ProcessHandle current = ProcessHandle.current();

current.info()

       .totalCpuDuration()

       .ifPresent(d -> System.out.println("Total cpu duration :" + d));

current.children()

       .forEach(p -> System.out.println("Pid:" + p.getPid()));

JEP 269: Convenience Factory Methods for Collections。

根据统计,在实际应用中,非常多的集合是有限元素的不可变示例。在历史版本中,需要非常繁琐的代码:

Set<String> set = new HashSet<>();

set.add("a");

set.add("b");

set.add("c");

set = Collections.unmodifiableSet(set);

利用新的静态工厂方法,一行代码就搞定!

Set<String> alphabet = Set.of("a", "b", "c");

注意,这是 unmodifiable 不是 immutable 哦。

JEP 166: Java 并发(Concurrency)API 更新。

提供了一个最小集合的 API 以支持 Reactive Stream,也就是所谓的 Flow API (Publisher, Subscriber, Processor)。开发者可以异步的方式处理数据流(Stream)而不是直接操作线程、同步等,进而避免很多并发问题,并且开发者可以利用 Back-Pressure 机制等,良好地(Memory-efficient)处理数据压力。目前,在新的 HTTP/2 Client API 里就有使用,感兴趣的话可以看看相关源代码。与此同时,改进了 CompletableFuture API,增强一些 time-based 的操作,并支持增强扩展性,比如实现一个子类替换 executor。

还有一些相对底层的 API,比如 JEP 259:Stack-Walking API,提供高效的标准 API去遍历 stack; JEP 193:Variable Handles, VarHandle 是把 Unsafe 之类的底层 fence 操作暴露出来。

下面,我们看看新的标准和协议。

安全方面的新标准和协议:

  • JEP 219: 支持Datagram Transport Layer Security (DTLS)。支持DTLS version 1.0 (RFC 4347) and 1.2 (RFC 6347),以提供安全的UDP传输。目前,基于UDP实现的类似SIP或者电子游戏协议,被证明是很有实际价值的。

  • JEP 229: 默认keystore格式从JKS替换为PKCS12。

  • JEP 244: TLS Application-Layer Protocol Negotiation(ALPN) Extension, 这是完整支持HTTP/2协议的前提之一。

  • JEP 249: 支持OCSP Stapling for TLS,减少证书状态验证的网络开销,提高性能。

  • JEP 273: 实现基于DRBG的SecureRandom,对于Deterministic Random Bit Generator (DRBG)机制,您可以参考NIST 800-90Ar1相关文档。

  • JEP 287: SHA-3 Hash Algorithms。

网络方面,主要有JEP 110: HTTP/2 client API,支持 HTTP 1.1,HTTP/2 和 WebSocket协议,实现了全新的 HTTP client API,用于替换老旧的HttpURLConnection。这个 API 是一个高性能、简化、轻量级的 API,同时支持同步和异步操作模式,充分利用了 Reactive style 编程。但是,在 Java 9 中,还处于 incubator 阶段,未来版本进一步完善,并在恰当时机转变为标准 API。

我这里有些举例的代码片段:

HttpClient client = HttpClient.newBuilder()

               .sslContext(sslContext)

               .version(HTTP_2)

               .build();

    HttpRequest req = HttpRequest.newBuilder(uri)

               .POST()

               .build();

    client.sendAsync(req, abodyhandler)

              .thenApply(…);

可以看到广泛使用了Builder模式,fluent风格。

编码方面,Java SE 9 支持:

  • JEP 227: Unicode 7.0

  • JEP 267: Unicode 8.0

  • JEP 226: UTF-8 Property Files,在历史版本中,属性文件是基于ISO-8859-1,不支持的字符需要显示的替换为转义序列,Java 9 改进了属性文件和ResourceBundle API以支持 UTF-8

API性能优化,我想介绍下面几点:

  • JEP 254:Compact String,Java 9 中,修改 String 实现,以 byte[] 数组和一个编码标记替换 char[] (16 bits) 数组,这样 Latin 语系编码字符串会节省近半空间。这个修改对 API 的使用者完全透明。

  • JEP 232:提高安全应用性能。 开启security manager通常会导致10-15%的性能下降,Java 9 的改进显著降低了开销。如果有兴趣可以看看具体的代码,具体的优化包括用标准的并发容器替换自定义的同步逻辑,或者去掉不必要的检查等等。

  • JEP 24:利用CPU指令优化GHASH和RSA。这是充分利用Intel x64或者SPARC CPU的部分新指令。部分加密函数的性能提高非常显著,比如在 benchmark 中,相比于 JDK 8,AES 性能提高了至少 8 倍。这是相对保守的数据,测试数据大多在几十倍提升。

第三,语言和工具。

JEP 222: jshell: The Java Shell (Read-Eval-Print Loop -REPL)

Jshell 是一个有趣的新工具,可以简单易用的交互式执行 Java 代码。我们马上试试看,打开command-line,然后执行“Path-to-JDK-9\bin\jshell”,就会出现一个交互界面,您可以输入 /help  来查看各种选项。

下面,我们实验一下前文介绍的 ProcessHandle API:

JEP 238: Multi-Release JAR Files,扩展了JAR文件格式,允许不同版本class文件共存,支持为不同JDK版本提供不同的代码实现。因为某些产品需要支持不同版本的Java,具体实现可能出现不可避免的区别,具体JAR文件结构如下图:

Java 9提供了新的javac选项“--release”, "Javac --release N"在语义上等价于:"Javac -source N -target N -bootclasspath rtN.jar"。历史版本的信息被压缩保存在jdk里面,这个大大简化了多版本编译的问题。

JEP 225: Javadoc Search,这是个不起眼,但是非常实用的功能,个人非常喜欢。可以看我下面的示例,马上试试吧.

另外, 语言方面,Java 9 处理了 Project Coin / JSR 334 (Java SE 7)的一些遗留问题:

  • 允许 @SafeVargs 使用在private instance methods

  • 允许 effectively-final变量用于 try-with-resources语句

  • 如果类型推断有效,允许”<>”用于匿名类。

  • “_” 不再是合法的identifier名称,大家可以打开 IDE 试试,呵呵。

  • 支持private interface methods,这主要是适用于抽象interface method中的内部共用部分逻辑。

第四,JVM 新特性

JEP 248: 将 G1 作为默认垃圾收集器。目前 server 模式的默认选项是 ParallelGC(吞吐量优先)。一般认为通用场景中,延迟比吞吐量更能提高用户体验,G1 可以直接设定延迟目标,达到延迟 SLA 要求。而且最坏场景的延迟表现优于 CMS(设计原理导致碎片化问题)。

JEP 295: Ahead-of-Time Compilation,所谓的 AOT。利用新的编译工具 jaotc,可以直接把class编译成类似类库的文件。举例:

jaotc –output libHelloWorld.so HelloWorld.clas

然后使用时,只要:

java -XX:AOTLibrary=./libHelloWorld.so HelloWorld

AOT可以大大提高启动性能,目前还是实验阶段,支持Linux x64平台。

JEP 214: 移除过时的GC组合,移除在JDK 8中标记过时的Incremental CMS (iCMS),大家可以参考下图:

注意,输入 Java 不支持的参数,不再是 warning,而是 error,直接在启动阶段就不再允许。

另外, GC 方面还有一个一定潜在影响的 JEP 291:Deprecate CMS,在 Java 9 开发阶段进行的沟通中,并没有社区成员承诺承担维护 CMS 的责任。建议 CMS 使用者可以开始考虑切换到 G1 等垃圾收集器。

JEP 158 / JEP 271: 统一日志( JVM / GC ),引入适用于 JVM 各个模块的通用日志机制,并在此基础上解决过于碎片化的 JVM 日志选项。

一些 JVM 性能优化工作,大家可能会感兴趣,比如:

  • JEP 143: 改进竞争锁( Contended Locking)改进高度竞争( high-contended)的 Java Object Monitor 性能。高度竞争可以理解为多个(大量)线程同时试图获取一个锁,在 Java9 里,实现了更快的 Java monitor enter, exit, notify / notifyAll 等。

  • JEP 285: Spin-Wait Hints。 Thread 新增一个方法 onSpinWait()。用于优化程序,尤其是运行在多核 CPU 时,在 busy-locking 时的性能表现,提高反应速度。但是注意,它需要利用 x86 的 pause 指令,所以前提是相应的 CPU 支持这个指令,否则,和现有行为没有区别。

前面谈了好多 Java9 新特性,我们看看 Java 未来发布模式的可能变化,主要参考了相关博客:

https://blogs.oracle.com/Java-platform-group/faster-and-easier-use-and-redistribution-of-java-se

该文透露出主要有几个重要信息:

  • 从 JDK9 GA, Oracle 计划发布 OpenJDK builds 基于 GPL。

  • Oracle 将逐步开源 Java Flight Recorder 之类的商业特性贡献给 Open JDK。

建议未来会切换为以时间驱动的发布模式,六个月的发布周期针对企业需求,以三年为周期发布 Long Term Support 版本

在刚刚结束的 JavaOne 大会上,除了 Java 领域本身的进一步开源和支持, Oracle 还现场源了非常棒的 serverless 框架, project Fn,该框架也将 Java 作为首选支持的编程语言,这些都是令人兴奋的积极变化。

Q&A

(作者注:下面是部分问答,特别强调,任何表述仅代表个人观点,希望集中于技术交流)

提问 1: Java9 怎么避免 jar hell?

杨晓峰:建议使用 JPMS 模块化,明确地定义模块的边界和依赖。当然,这样说比较范范,后续还是需要更多社区的实践和反馈。现在还有很多场景,并不在 JSR 376 的职责范围,比如,真正意义上的模块多版本。当前,加载不同版本的模块,可以尝试创建不同 Layer 的方式来实现。

提问 2: aot 可以直接编译到本地可执行文件吗 还是也需要 JRE 来执行? 还有现在 aot 的兼容性何如?

杨晓峰:不能直接编译成为可执行文件,这不是 jaotc 目前的职责;如果要定制和打包最终可执行的应用,目前还是需要 jlink 或者 javapackager 之类的工具。另外 aot 还是实验阶段,最初的版本只支持 Linux x64。

提问 3: Java 的 pattern matching 大概会在那个版本推出?

杨晓峰:这个特性 Brain Goetz 已经在社区里提过,有兴趣可以关注 OpenJDK 的相关邮件列表,获取最近进展,我无法提供任何有关版本和日程方面的信息。

提问 4:想请问 Oracle 和 JCP 之间是怎样的协作关系, JCP 有自己的 JSR, Oracle 推出了 jep,看 jep0 是说在提交 jsr 前给开发者一个更充分的准备,但不太清楚这两者之间如何协作, jep 会升级为 jsr 吗?可否介绍一下这几个概念

杨晓峰:坦白说 JCP 流程方面的东西我不是特别理解,也不好过多评价。 JEP 不是 JSR 的替代,它更是一个跟踪建议、设计、开发流程的概念。 JSR 是更正式的规范,其他公司可以根据这个 specification 做相应的参考实现。

提问 5: Java9 模块化能够很好的解决 class 的依赖问题,不过靠 maven 我们我们已经可以去解决依赖问题, Java9 的 module-info 对于开发应用有什么好处呢?对于 JDK 本身的好处似乎比较大?从应用层面来说,似乎现有的 maven 已经够用了。

杨晓峰:个人认为,这是不同层面的问题, JPMS 不能替代 build 工具的部分功能 , 而且,确实项目的初衷之一,就是解决 JDK 自身的模块化。对于好处,我可以举个,我现在写一个 serverless 应用,利用 jlink 工具去掉不必要的依赖, Docker image 只有几十兆大小,这在云计算环境并不是无所谓的。 Maven 也第一时间发布了对 Java 9 的支持, Java 社区和 Apache 等开源组织或者第三方公司有非常好的沟通。

提问 6: O 记是要让大家免费使用 JFR 了吗?

杨晓峰:免费不是技术问题,个人也无法回答。我谈到的是开源方面的信息,根据上面提到的博客( https://blogs.oracle.com/Java-platform-group/faster-and-easier-use-and-redistribution-of-java-se),未来会开源JFR等商业特性, Oracle JDK 和 Open JDK 做到 zero difference。可以看出 Oracle 对 Java 的支持是不予余力的,毕竟 Oracle JDK 有很多厉害的工具或者特性,具备很多同类产品没有的能力。

提问 7: Java 有计划对“协程”提供 runtime 级别的支持嘛?

杨晓峰:我注意到 OpenJDK 有相关项目提案,比如 http://cr.openjdk.Java.net/~rpressler/loom/Loom-Proposal.html

提问 8: kotlin 可能替代 Java 吗?你是怎么看待两个语言未来的发展方向?

杨晓峰:这个我不能做任何评价, " 臣妾真的做不到啊”。不要忽略了 , 全球至少 1200 万的 Java 开发人员和社区 , 还有海量的高质量类库、工具等等,这也代表了公司和机构天文数字的投入。历史上太多开源项目或语言起起伏伏,真正能够经久不衰的, Java 算是一个。

高可用架构.png

原文来自:高可用架构

声明:所有来源为“聚合数据”的内容信息,未经本网许可,不得转载!如对内容有异议或投诉,请与我们联系。邮箱:marketing@think-land.com

0512-88869195
数 据 驱 动 未 来
Data Drives The Future