全新的HTTP 客户端API
HTTP，用于传输网页的协议，早在1997年就被采用在目前的1.1版本中。直到2015年，HTTP2才成为标准。
HTTP/1.1和HTTP/2的主要区别是如何在客户端和服务器之间构建和传输数据。HTTP/1.1依赖于请求/响应周期。HTTP/2允许服务器“push”数据：它可以发送比客户端请求更多的数据。这使得它可以优先处理并发送对于首先加载网页至关重要的数据。
这是Java 9开始引入的一个处理HTTP请求的的HTTP Client API，该API支持同步和异步，而在Java 11中已经为正式可用状态，你可以在java.net包中找到这个API。
它将替代仅适用于blocking模式的HttpURLConnection（HttpURLConnection是在HTTP 1.0的时代创建的，并使用了协议无关的方法），并提供对WebSocket和HTTP/2的支持。
HttpClient client = HttpClient.newHttpClient(); HttpRequest request = HttpRequest.newBuilder(URI.create("http://127.0.0.1:8080/test/")).build(); BodyHandler<String> responseBodyHandler = BodyHandlers.ofString(); HttpResponse<String> response = client.send(request, responseBodyHandler); String body = response.body(); System.out.println(body);
HttpClient client = HttpClient.newHttpClient(); HttpRequest request = HttpRequest.newBuilder(URI.create("http://127.0.0.1:8080/test/")).build(); BodyHandler<String> responseBodyHandler = BodyHandlers.ofString(); CompletableFuture<HttpResponse<String>> sendAsync = client.sendAsync(request, responseBodyHandler); sendAsync.thenApply(t -> t.body()).thenAccept(System.out::println);//HttpResponse<String> response = sendAsync.get(); // String body = response.body();//System.out.println(body);
更简化的编译运行程序
看下面的代码。
//编译
javac Javastack.java
//运行
java Javastack
在我们的认知里面，要运行一个Java源代码必须先编译，再运行，两步执行动作。而在未来的Java 11版本中，通过一个java命令就直接搞定了，如以下所示：
java Javastack.java
一个命令编译运行源代码的注意点：
执行源文件中的第一个类, 第一个类必须包含主方法。
并且不可以使用其它源文件中的自定义类, 本文件中的自定义类是可以使用的。
废弃Nashorn引擎
废除Nashorn javascript引擎，在后续版本准备移除掉，有需要的可以考虑使用GraalVM。
ZGC
GC是java主要优势之一。然而,当GC停顿太长,就会开始影响应用的响应时间。消除或者减少GC停顿时长, java将对更广泛的应用场景是一个更有吸引力的平台。此外,现代系统中可用内存不断增长,用户和程序员希望JVM能够以高效的方式充分利用这些内存,并且无需长时间的GC暂停时间。
ZGC, A Scalable Low-Latency Garbage Collector(Experimental)ZGC,这应该是JDK11最为瞩目的特性,没有之一。但是后面带了Experimental,说明这还不建议用到生产环境。
ZGC是一个并发,基于region,压缩型的垃圾收集器,只有root扫描阶段会STW(stop the world),因此GC停顿时间不会随着堆的增长和存活对象的增长而变长。
优势：
GC暂停时间不会超过10ms
既能处理几百兆的小堆,也能处理几个T的大堆(OMG)
和G1相比,应用吞吐能力不会下降超过15%
为未来的GC功能和利用colord指针以及Load barriers优化奠定基础
初始只支持64位系统
ZGC的设计目标是：
支持TB级内存容量，暂停时间低（），对整个程序吞吐量的影响小于15%。将来还可以扩展实现机制，以支持不少令人兴奋的功能，例如多层堆（即热对象置于DRAM和冷对象置于NVMe闪存），或压缩堆。
在当前JDK中看不到什么？
一个标准化和轻量级的JSON API
一个标准化和轻量级的JSON API被许多Java开发人员所青睐。但是由于资金问题无法在Java当前版本中见到，但并不会削减掉。Java平台首席架构师MarkReinhold在JDK 9邮件列中说：“这个JEP将是平台上的一个有用的补充，但是在计划中，它并不像Oracle资助的其他功能那么重要，可能会重新考虑JDK 10或更高版本中实现。”
新的货币API
对许多应用而言货币价值都是一个关键的特性，但JDK对此却几乎没有任何支持。严格来讲，现有的java.util.Currency类只是代表了当前ISO 4217货币的一个数据结构，但并没有关联的值或者自定义货币。JDK对货币的运算及转换也没有内建的支持，更别说有一个能够代表货币值的标准类型了。
此前，Oracle公布的JSR 354定义了一套新的Java货币API：JavaMoney，计划会在Java9中正式引入。但是目前没有出现在JDK新特性中。不过，如果你用的是Maven的话，可以做如下的添加，即可使用相关的API处理货币：
<dependency> <groupId>org.javamoney</groupId> <artifactId>moneta</artifactId> <version>0.9</version> </dependency>
展望
随着云计算和AI等技术浪潮，当前的计算模式和场景正在发生翻天覆地的变化，不仅对Java的发展速度提出了更高要求，也深刻影响着Java技术的发展方向。传统的大型企业或互联网应用，正在被云端、容器化应用、模块化的微服务甚至是函数(FaaS，Function-as-a-Service)所替代。
Java虽然标榜面向对象编程，却毫不顾忌的加入面向接口编程思想，又扯出匿名对象之概念，每增加一个新的东西，对Java的根本所在的面向对象思想的一次冲击。反观Python，抓住面向对象的本质，又能在函数编程思想方面游刃有余。Java对标C/C++，以抛掉内存管理为卖点，却又陷入了JVM优化的噩梦。选择比努力更重要，选择Java的人更需要对它有更清晰的认识。
Java 需要在新的计算场景下，改进开发效率。这话说的有点笼统，我谈一些自己的体会，Java 代码虽然进行了一些类型推断等改进，更易用的集合API 等，但仍然给开发者留下了过于刻板、形式主义的印象，这是一个长期的改进方向。
