Oracle has announced the first set of enhancement proposals (known as JEPs) for Java 9 which has been targeted for release in early 2016.
Three new APIs have been announced:
Process API Updates for interacting with non-Java operating system processes. The limitations of the current API often force developers to resort to native code. The main risk with this API is differences between operating systems, in particular Windows.The design of this API needs to accommodate possible deployment on smaller devices with different operating system models. It should also take into account environments where multiple Java virtual machines are running in the same operating system process. These considerations could lead to a more abstract API and/or increase the design effort.
New HTTP Client that includes HTTP/2 support.
Problems with the existing API and implementation:
- URLConnection based API was designed with multiple protocols in mind, nearly all of which are defunct now (ftp, gopher, etc.)
- predates HTTP 1.1 and is too abstract
- hard to use (much behavior undocumented)
- works in blocking mode only (one thread per request/response)
- very hard to maintain
Https 2.0 support depends on TLS ALPN (Application Layer Negotiation Extension) which is not currently supported in JDK. The Http 2.0 spec itself is still in internet-draft form, but is expected to be submitted as a draft standard Nov 2014.
New lightweight JSON API which provide a light-weight API for consuming and generating JSON documents and data streams.. The latter is expected to build upon the JSON support already standardized as part of JSR 353.
There are also three JVM / performance related features announced:
Improve contended locking for better performance when threads are competing for access to objects. Improving contended locking will significantly benefit real world applications, in addition to industry benchmarks such as Volano and DaCapo.
This project will explore performance improvements in the following areas related to contended Java Monitors:
- Field reordering and cache line alignment
- Speed up
- Fast Java monitor enter operations
- Fast Java monitor exit operations
- Fast Java monitor
- Adaptive spin improvements and SpinPause on SPARC
Segmentation of the JIT compiler’s code cache (for better JIT performance on large applications). Divide the code cache into distinct segments, each of which contains compiled code of a particular type, in order to improve performance and enable future extensions.
The organization and maintenance of compiled code has a significant impact on performance. Instances of performance regressions of several factors have been reported if the code cache takes the wrong actions. With the introduction of tiered compilation the role of the code cache has become even more important, since the amount of compiled code increases by a factor of 2X–4X compared to using non-tiered compilation. Tiered compilation also introduces a new compiled code type: instrumented compiled code (profiled code). Profiled code has different properties than non-profiled code; one important difference is that profiled code has a predefined, limited lifetime while non-profiled code potentially remains in the code cache forever.
The current code cache is optimized to handle homogeneous code, i.e., only one type of compiled code. The code cache is organized as a single heap data structure on top of a contiguous chunk of memory. Therefore, profiled code which has a predefined limited lifetime is mixed with non-profiled code, which potentially remains in the code cache forever. This leads to different performance and design problems. For example, the method sweeper has to scan the entire code cache while sweeping, even if some entries are never flushed or contain non-method code.
Further development of the “smart” Java compiler, sjavac, which promises parallel and shared compilation among other features.
Due to various issues relating to stability and portability,
sjavac is not used by default in the JDK build scripts. The first goal of this JEP is to resolve these issues. This involves making sure the tool produces reliable results on all software/hardware configurations at all times.
The overarching goal is to improve the quality of
sjavac to the point where it can serve as a general purpose
javac wrapper able to compile large arbitrary Java projects.
A follow-on project will explore how
sjavac is to be exposed in the JDK tool chain, if at all; this might be a separate supported standalone tool, an unsupported standalone tool, integration with
javac, or something else.
Finally, one tantalizing feature has been promised in the form of JEP 201 – Modular Source Code. This is not, as yet, the modularity solution known as Project Jigsaw (initially targeted as part of Java 8).
Project Jigsaw aims to design and implement a standard module system for the Java SE Platform and to apply that system to the Platform itself, and to the JDK. Its primary goals are to make implementations of the Platform more easily scalable down to small devices, improve the security and maintainability, enable improved application performance, and provide developers with better tools for programming in the large.
This JEP is part of the first phase of Project Jigsaw; later JEPs will modularize the JRE and JDK images and then introduce a module system.
The motivations to reorganize the source code at this early stage are to:
- Give JDK developers the opportunity to become familiar with the modular structure of the system;
- Preserve that structure going forward by enforcing module boundaries in the build, even prior to the introduction of a module system; and
- Enable further development of Project Jigsaw to proceed without always having to “shuffle” the present non-modular source code into modular form.