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.
If you have been reading our reports on adversarial images, the headline should come as no surprise. What is a surprise is the way that AI researchers are regarding such images as security threats rat [ ... ]
The I-Programmer team reports a lot of news and originates loads of helpful articles, but there's far more out there than we can possibly cover. So from time to time we trawl through other people's bl [ ... ]