JDK 9 – a letter to Santa?!

Attila Mihaly BalazsDecember 22nd, 2014Last Updated: December 22nd, 2014

1 15 9 minutes read

As everybody knows, winter (especially the time before Christmas) is a proper time for dreaming and hoping a moment when dreams seem to be touchable. A moment when children and grown-ups write on paper or in their thoughts fictive or real letters to Santa Claus, hoping their dreams will become reality. This is catchy, as even the people behind OpenJDK expressed their wishes for the (of java) on the first day of December, when they published an updated list JEPs. Hold on, don’t get excited just yet…as we bitterly know, theywill might become reality somewhere in early 2016. Or at least this is the plan, and history showed us what sticking to a plan means.

Of course, the presence of a JEP in the above mentioned list, doesn’t mean that the final release will contain it as the JEP process diagram clearly explains, but for the sake of winter fairy tails we will go through the list and provide a brief description what the intended purpose of each item is.

Disclaimer: the list of JEPs is a moving target, since the publication of this article the list changed at least once.

JEP 102: Process API Updates

Those of you who where lucky not that good, it seems that santa punished you and you had the pleasure of working with java’s process api and of course met his limitations. After the changes in JDK 7, the current JEP comes to improve this API even further and to give us the ability to:

to get the pid (or equivalent) of the current Java virtual machine and the pid of processes created with the existing API
to get/set the process name of the current Java virtual machine and processes created with the existing API (where possible)
to enumerate Java virtual machines and processes on the system. Information on each process may include its pid, name, state, and perhaps resource usage
to deal with process trees, in particular some means to destroy a process tree
to deal with hundreds of sub-processes, perhaps multiplexing the output or error streams to avoid creating a thread per sub-process

I don’t know about you, but I can definitely find at least a couple of scenarios where I could put at good use some of this features, so fingers crossed.

JEP 143: Improve Contended Locking

I had the luck and pleasure to be present to a performance workshop the other days with Peter Lawrey, and one of the thumb rules of java performance tuning was: the least concurrent an application, the more performant it is. With this improvement in place, the rules of performance tuning might need to find another thumb rule, as with this JEP implemented the latency of using monitors in java is targeted. To be more accurate, the targets are:

Field reordering and cache line alignment
Speed up PlatformEvent::unpark()
Fast Java monitor enter operations
Fast Java monitor exit operations
Fast Java monitor notify/notifyAll operations
Adaptive spin improvements and SpinPause on SPARC

JEP 158: Unified JVM Logging

The title kind of says it all. If you are working with enterprise applications you had to deal at least once or twice with a gc log and I suppose raised at least an eyebrow (if not both) when seeing the amount of information and the way it was presented there. Well, if you were “lucky” enough you probably migrated between JVM versions, and then definitely wanted/needed another two eyebrows to raise when you realised that the parsers you’ve built for the previous version has issues dealing with the current version of the JVM logging. I suppose I can continue with why is bad, but let’s concentrate on the improvements, so hopefully by the next release we will have a reason to complain that before it was better.

The gc logging seems to try to align with the other logging frameworks we might be used too like log4j. So, it will work on different levels from the perspective of the logged information’s criticality (error, warning, info, debug, trace) their performance target being that error and warning not to have any performance impact on production environments, info suitable for production environments, while debug and trace don’t have any performance requirements. A default log line will look as follows:

[gc][info][6.456s] Old collection complete

In order to ensure flexibility the logging mechanisms will be tuneable through JVM parameters, the intention being to have a unified approach to them. For backwards compatibility purposes, the already existing JVM flags will be mapped to new flags, wherever possible.

To be as suitable as possible for realtime applications, the logging can be manipulated through jcmd command or MBeans.

The sole and probably the biggest downside of this JEP is that it targets only providing the logging mechanisms and doesn’t necessarily mean that the logs will also improve. For having the beautiful logs we dream of maybe we need to wait a little bit more.

JEP 165: Compiler Control

As you probably know, the java platform uses JIT compilers to ensure an optimum run of the written application. The two existing compilers intuitively named C1 and C2, correspond to client(-client option) respectively server side application (-server option). The expressed goals of this JEP is to increase the manageability of these compilers:

Fine-grained and method-context dependent control of the JVM compilers (C1 and C2).
The ability to change the JVM compiler control options in run time.
No performance degradation.

JEP 197: Segmented Code Cache

It seems that JVM performance is targeted in the future java release, as the current JEP is intended to optimise the code cache. The goals are:

Separate non-method, profiled, and non-profiled code
Shorter sweep times due to specialized iterators that skip non-method code
Improve execution time for some compilation-intensive benchmarks
Better control of JVM memory footprint
Decrease fragmentation of highly-optimized code
Improve code locality because code of the same type is likely to be accessed close in time
- Better iTLB and iCache behavior
Establish a base for future extensions
- Improved management of heterogeneous code; for example, Sumatra (GPU code) and AOT compiled code
- Possibility of fine-grained locking per code heap
- Future separation of code and metadata (see JDK-7072317)

The first two declared goals, are from my perspective quite exciting, with the two in place the sweep times of the code cache can be highly improved by simply skiping the non-method areas – areas that should exist on the entire runtime of the JVM.

JEP 198: Light-Weight JSON API

The presence of this improvement shouldn’t be a surprise, but for me it is surprising that it didn’t make sooner in the JDK, as JSON replaced XML as the “lingua-franca” of the web, not only for reactive JS front-ends but also for structuring the data in NoSQL databases. The declared goals of this JEP are:

Parsing and generation of JSON RFC7159.
Functionality meets needs of Java developers using JSON.
Parsing APIs which allow a choice of parsing token stream, event (includes document hierarchy context) stream, or immutable tree representation views of JSON documents and data streams.
Useful API subset for compact profiles and Java ME.
Immutable value tree construction using a Builder-style API.
Generator style API for JSON data stream output and for JSON “literals”.
A transformer API, which takes as input an existing value tree and produces a new value tree as result.

Also, the intention is to align with JSR 353. Even if the future JSON will have limited functionalities comparing to the already existing libraries, it has the competitive advantage of integrating and using the newly added features from JDK 8 like streams and lambdas.

JEP 199: Smart Java Compilation, Phase Two

The sjavac is a wrapper to the already famous javac, a wrapper intended to bring improved performance when compiling big sized projects. As in the current phase, the project has stability and portability issues, the main goal is to fix the given issues and to probably make it the default build tool for the JDK project. The stretched goal would be to make the tool ready to use for projects other than JDK and probably integration with the existing toolchain.

JEP 201: Modular Source Code

The first steps in the direction of project jigsaw’s implementation, having the intention of reorganising the source code as modules enhancing the build tool for module building and respecting the module boundaries.

JEP 211: Elide Deprecation Warnings on Import Statements

The goal of this JEP is to facilitate making large code bases clean of lint warnings. The deprecation warnings on imports cannot be suppressed using the @SuppressWarnings annotation, unlike uses of deprecated members in code. In large code bases like that of the JDK, deprecated functionality must often be supported for some time and merely importing a deprecated construct does not justify a warning message if all the uses of the deprecated construct are intentional and suppressed.

JEP 212: Resolve Lint and Doclint Warnings

As the lunch date for the JDK 9 is early 2016, this JEP is perfect for that time of the year and the corresponding chores: the spring clean-up. The main goal of it is to have a clean compile under javac’s lint option (-Xlint:all) for at least the fundamental packages of the platform.

JEP 213: Milling Project Coin

Project coin’s target starting with JDK 7 was to bring some syntactic sugar in the java language, to bring some new clothes on the mature platform. Even if it didn’t bring any improvements to the performance of the language, it increased the readability of the code hence it brought a plus to one of the most important assets of a software project, in my opinion, a more readable code base.

This JEP targets four changes:

Allow @SafeVargs on private instance methods.
Allow effectively-final variables to be used as resources in the try-with-resources statement.
Allow diamond with inner classes if the argument type of the inferred type is denotable.
Complete the removal, begun in Java SE 8, of underscore from the set of legal identifier names.

JEP 214: Remove GC Combinations Deprecated in JDK 8

Spring time cleaning continues with the removal of the JVM flags deprecated in Java 8 release, so with release 9 the following options will no longer be supported:

DefNew + CMS       : -XX:-UseParNewGC -XX:+UseConcMarkSweepGC
ParNew + SerialOld : -XX:+UseParNewGC
 
ParNew + iCMS      : -XX:+CMSIncrementalMode -XX:+UseConcMarkSweepGC
ParNew + iCMS      : -Xincgc
 
DefNew + iCMS      : -XX:+CMSIncrementalMode -XX:+UseConcMarkSweepGC -XX:-UseParNewGC
CMS foreground     : -XX:+UseCMSCompactAtFullCollection
CMS foreground     : -XX:+CMSFullGCsBeforeCompaction
 
CMS foreground     : -XX:+UseCMSCollectionPassing

JEP 216: Process Import Statements Correctly

This JEP targets to Fix javac to properly accept and reject programs regardless of the order of import statements and extends and implements clauses.

JEP 219: Datagram Transport Layer Security (DTLS)

The increasing number of application layer protocols have been designed that use UDP transport,in particular, protocols such as the Session Initiation Protocol (SIP) and electronic gaming protocols made security concerns higher than ever especially since TLS can be used only over reliable protocols like TCP. The current JEP intends to fill this gap by defining an API for Datagram Transport Layer Security (DTLS) version 1.0 (RFC 4347) and 1.2 (RFC 6347).

JEP 220: Modular Run-Time Images

Comes as a follow-up step to JEP 201, with the intention to restructure the JDK and run-time environment to accommodate modules and to improve performance, security, and maintainability. Define a new URI scheme for naming the modules, classes, and resources stored in a run-time image without revealing the internal structure or format of the image. Revise existing specifications as required to accommodate these changes.

JEP 224: HTML5 Javadoc

As the HTML standard version reached version 5, the javadoc pages of the JDK need to keep up the pace as well, hence upgrade from HTML 4.01.

JEP 231: Remove Launch-Time JRE Version Selection API updates

Remove the ability to request (by using -version:), at JRE launch time, a version of the JRE that is not the JRE being launched. The removal will be done stepwise: a warning will be emitted in version 9 while Java 10 will probably throw an error.

This is the current form of the list of enhancements prepared for JDK 9, to be honest when I first looked over it, I was somehow blue but after reading more into it I became rather excited as it seems that java is yet to start the road for another adventure and they need all the help they could get. So if you want to get involved (please do!), a later blog post of the java advent series will present you how to get involved. Imagine it like the fellow ship of the ring, but target of the adventure is building java not destroying the ring…who might Mr. Frodo be?

Reference:

JDK 9 – a letter to Santa?! from our JCG partner Olimpiu Pop at the Java Advent Calendar blog.