Oracle has announced the first set of proposed improvements for inclusion in Java 9.

The suggestions have been made as JEPs (Java Enhancement Proposals). JEPs provide a way for new features to be discussed and developed without going through a full formal specification (JSR). The less formal approach makes it possible to put forward proposals that overcome some specific problem.

The idea is that if a JEP is popular and successful, it will then be put forward as part of the next full formal specification. This approach makes it possible to have incremental JEPs, rather than one large group of changes at once. This is the first time JEPs have been used, and the list Oracle has come up with is relatively small.

The proposed JEPs for JDK 9 start with improvements to the process API used for controlling and managing operating-system processes. Java SE provides limited support for native operating-system processes, with a basic API to setup the environment and start a process. The suggestion is this should be extended so developers no longer have to resort to native code.

Improvements to contended locking are the next suggestion, with the aim of improving the performance of contended Java object monitors, as measured by a set of benchmarks and tests. This would result in improved performance in situations where multiple threads compete for access to objects.

Another JEP is for the provision of a segmented code cache that will 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. This would be particularly applicable to large applications.

The development of a lightweight JSON API for consuming and generating JSON documents and data streams has also been suggested. This would have the goal of meeting the needs of Java developers using JSON.

A better version of the Smart Java Compiler (sjavac) is another proposal, Smart Java compilation Phase 2. The idea is that sjavac should be improved so that it can be used by default in the JDK build, and that it should be generalized so that it can be used to build large projects other than the JDK.

The final JEP is for modular source code. This is an internal exercise to reorganize the JDK source code into modules, to enhance the build system to compile modules, and to enforce module boundaries at build time.

The full list of JEPs can be seen on the OpenJDK website.  

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: [email protected]