Java 9 features

Oracle has announced that the first set of enhancement plans (known as JEPs) for Java 9 has been confirmed to be released in early 2016.

Three new APIs have been announced:

The Process API can interact with non-JAVA related processes in the operating system after the update. The currently used API has many limitations, which forces developers to often resort to native code. The main risk with this API is the heterogeneous nature of operating systems, especially Windows. The design of the API needs to adapt to the deployment of small devices on different operating systems. It should also consider the environment where multiple Java virtual machines run in the same operating system process. These considerations will lead to a more abstract API, which will increase the design workload.

　New HTTP client, introducing support for HTTP/2.

Problems and implementation of existing APIs:

APIs based on URLConnection are designed with multiple protocols in mind, many of which have been abandoned (ftp, gopher, etc.)

Early HTTP 1.1 was too abstract

difficult Usage (many behaviors are not documented)

Can only work in blocking mode (one thread per request/response)

Very difficult to maintain

　Https 2.0 support relies on TLS ALPN (Application Layer Negotiation Extension), currently JDK Not supported in 2014, the HTTP 2.0 specification itself is still in Internet Draft form, but it is expected to become an official draft in 2014.

　New lightweight JSON API: It provides a lightweight API for processing and generating JSON documents and data streams. The latter is based on standardized JSON support and is part of JSR 353.

There are also three JVM and performance-related features announced:

Improved contention locks, designed to improve performance when threads compete to access objects. Improving contention locking would be of great benefit to real-world applications, especially against industrial benchmarks such as Volano and DaCapo.

This project will explore performance improvements in the following areas related to competing Java monitors:

Field reordering and cache line alignment

Speed ​​up PlatformEvent::unpark()

Fast Java monitor entry operations

Fast Java monitor exit operations

Fast Java monitor notify/notifyAll operations

Adaptive spin improvements and SpinPause on SPARC

Split JIT compiler’s code cache ( for better JIT performance on large applications). Breaking the code cache into independent segments, each containing a specific form of compiled code, is intended to improve performance and support future expansion.

　The organization and maintenance of compiled code will have a huge impact on performance. If the code cache goes in the wrong direction, several instances of performance degradation will be known. After the introduction of multi-level compilation, the status of code caching becomes extremely important, because the amount of compiled code will increase by 2-4 times compared with not using multi-level compilation. Multi-level compilation also introduces a new type of compiled code: instrumented compiled code (isolated code). Alien code has different properties from non-profiled code. One important difference is that profiled code has a predefined restricted life cycle, in contrast to non-profiled code, which always remains in the code cache.

Existing code caching is optimized for a single code, that is, there is only one form of compiled code. The code cache is organized as a separate heap data structure located at the head of a contiguous memory block. As a result, profiled code with a predefined restrictive lifetime will be mixed with non-profiled code and remain permanently in the code cache, which introduces different performance and design issues. For example, the sweeper method will be forced to scan the entire code cache when scanning, even if some entities in it are never updated, or there is non-method code.

In-depth development of a "smart" Java compiler, called sjavac, which supports parallel and shared compilation, among other features.

Due to various stability and portability issues, sjavac is not used in JDK build scripts by default. The first goal of this JEP is to solve these issues, which involves ensuring that the tool can always Produces reliable results on all hardware and software configurations.

　The overall goal is to improve the quality of sjavac and make it a universal javac package capable of compiling various large-scale Java projects.

　Follow-up projects will continue to explore how to separate sjavac in the JDK tool chain, if possible. sjavac may become a standalone supported tool, a non-standalone tool integrated with javac, or something else.

Finally, an enticing feature has been promised in JEP 201: modular source code. This is actually what we once knew as the modular solution "Project Jigsaw" (originally targeted as part of Java 8).

　The Jigsaw project aims to design and implement a standardized module system for the Java SE platform, and apply it to its own platform, and then invest it in the JDK. Its initial goals are to make platform implementations more easily scalable to small devices, improve security and maintainability, improve application performance, and provide developers with better tools when faced with large applications.

This JEP is part of the first phase of the Jigsaw project. Next, the JEP will modularize the JRE and JDK images, and then introduce a module system.

The motivation for reorganizing the source code in the early stage is:

To give JDK developers the opportunity to become familiar with the modular structure of the system.

Continue to advance structure by enforcing module boundaries in builds, even before the module system is introduced.

In-depth development of Jigsaw projects instead of always "slowly" converting existing non-modular code into modular code.