The past 2017 has seen many unprecedented changes in the Java world, due in part to the introduction of Java 9, albeit nearly a year later.
Over time, however, one may find that the release of a Java 9 release is far less meaningful than the change in the Java release cycle that accompanies this new release to every six months. The change in the release cycle of Java versions means that in 2018 there will be two new versions of Java, not one.
The first new version coming out in 2018 is called Java 10, and the second new version is Java 11. While this naming scheme appears to be the same as the existing one, the new version can only be launched after major public debate and final consensus.
Given that new version rollouts will switch to such a strictly point-in-time cadence, it is expected that this will result in a narrower range of Java features released in each new version than has been seen so far. In the case of Java 10, this means that the number of new features will be quite small.
InfoQ has previously reported on the main features in Java 10, and we'll get back to them later. Since then, only some minor (Additional Unicode Extensions), cleanup (remove native header generation tools, provide default CA root certificate), experimental (Java-based JIT compilation) have been added to this version. Graal), or currently niche (support for heterogeneous memory architectures).
As for what features are considered in Java 11, it is currently a cloud cover. We can only confirm that the following features are under consideration:
Epsilon. A reference implementation of the Null garbage collection algorithm.
Dynamic Class File Constants. A platform feature primarily aimed at software library writers and advanced developers using the dynamic feature invokedynamic.
Tracks JIT compilation events at runtime.
This list of features is sure to fill up once the release date approaches. It's worth noting, however, that Java value types are not yet mentioned in the list. This is perhaps not unexpected, since implementing value types requires significant changes to the Java language and runtime, as well as a complete refactoring of the Java type system (including generics).
Although the current prototype is working, it is still a long way from feature delivery. The current state is only for low-level platform developers, and those accustomed to using reflective or MethodHandle-based tools. It seems uncanny that even though value types will be released as part of Java 11, Oracle has yet to make any public comment on when the feature is expected to be released.
However, if value types are not provided as part of Java 11, this will have a knock-on effect. The first Long Term Support (LTS) release containing value types will not be released until September 2021.
At the time of this writing, it is unclear whether the data classes feature already in the proposal will appear in Java 11. As Java language architect Brian Goetz puts it:
Data classes will be used to resolve the complex indirection that exists between the representation of the class and the API contract. By using data classes, the compiler can fill in some regular class members.
The data classes proposal shares some similarities with Scala's Case classes. But Goetz makes it clear that there are some possible changes in the design space of data classes, and the overall semantic meaning of this feature goes deeper than what we can see so far. The current concept of data classes is deeply tied to the pattern matching feature that is also under development. However, these two features may be available in different versions.
Related to the above two features is that the Switch form may be improved in the future. Switch statement blocks will be available as expressions or declarations.
This feature is relatively small and is expected to be delivered in Java 11, even if the data classes or pattern matching features are not yet implemented. But as things stand, the feature is still a JEP draft.
The final release in September has a feature completion date of June 2018. So we'll have to wait a few more months before the overall shape of Java 11 emerges.
Speaking of Java 10, its new features are still being confirmed, so it is still possible to add significant changes between now and the GA version. Regardless, developers can expect some new features to be added to Java 10 during these four months.
新的特性和增强一般通过 Java Enhancement Process（JEP）或 Java Community Process 标准请求（JSR）进行跟踪。因为 Java 10 的时间线较短，范围也相对较小，所以 Java 10 的变更将通过 JEP 进行跟踪。
有望被包含在 Java 10 中的特性是那些已经处于 Targeted 或 Proposed 状态的 JEP，它们包括：
286：本地变量类型推断
296：统一 JDK 仓库
304：垃圾回收器接口
307：G1 的并行 Full GC
310：应用程序类数据共享
312：ThreadLocal 握手机制
JEP 296 是一次纯粹的清理工作，而 JEP 304 加强了不同垃圾回收器的代码隔离，并为垃圾回收器引入更简洁的接口。
JEP 304 意味着厂商可以更自由地选择特定的 GC 算法来构建 JDK，因为现在有多种处于开发当中的 GC，如 Shenandoah、ZGC 和 Epsilon，在未来可以使用这些 GC 算法。社区也在努力弃用甚至移除 Concurrent Mark Sweep（CMS）垃圾回收器，只是目前还没有可用的替代品。
比较有意思的变更或许是 JEP 286，增强的本地变量类型推断可以让开发者免去很多变量申明模板代码。也就是说，在下一个版本中，下面的变量声明是合法的：
var list = new ArrayList<String>(); // infers ArrayList<String>
var stream = list.stream(); // infers Stream<String>这种语法只限于初始化过的本地变量和 for 循环中的本地变量。
它其实是个语法糖，在语义上并没有任何变化。不过，该特性有可能在 Java 开发者当中引起热议。其他三个变更都将在性能方面带来一些影响。
JEP 307 解决了 G1 垃圾回收器的一个问题——截止到 Java 9，G1 的 Full GC 采用的是单线程算法。也就是说，G1 在发生 Full GC 时会严重影响性能。JEP 307 的目的就是要采用并行 GC 算法，在发生 Full GC 时可以使用多个线程进行并行回收。
JEP 310 extends Class Data Sharing (CDS), the JVM can record some classes to a shared compressed file, which can be mapped to the JVM process the next time the JVM starts, thereby reducing startup time. This file can also be shared among multiple JVMs, which reduces memory usage when running multiple JVMs on the same machine.
This feature has existed since Java 5, but as of Java 9, it only allows the bootstrap class loader to load compressed classes. The purpose of JEP 310 is to extend this functionality so that applications and custom class loaders can also load compressed classes. This feature is currently only available in Oracle JDK, OpenJDK does not include it.
JEP plans to migrate this feature from Oracle's private repositories to public repositories, and from Java 10 onwards, regular releases (non-LTS) will use OpenJDK binary packages. This move shows that users are using this feature, so it needs to be supported in OpenJDK as well.
JEP 312 is designed to improve virtual machine performance, calling a callback on an application thread no longer requires a global virtual machine safepoint operation, which means that the JVM can stop a single thread. Some low-level improvements include:
Reduce the impact of stack trace sampling (eg profiling).
Reduce signal dependencies for better stack sampling.
Improved biased locking by stopping individual threads.
Removed some memory barriers from the JVM.
Overall, Java 10 does not appear to contain major new features or performance improvements. This is understandable, after all this is the first release under a new release cycle.
When learning java children's shoes, it is inevitable to encounter problems that you don't understand in learning. Add java learning skirts, and the group will live broadcast classes every day. If you need information, you can share it with everyone (667292192), whether you are a novice or a professional All levels can be added to exchange and learn.