As everybody knows, winter 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 of java, on the first day of December, when they published an updated JEPs list. Hold on, don't get excited just yet...as we bitterly know, they might become reality somewhere in early 2016. Or, at least, this is the plan, and history has shown 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 tales, we will go through the list and provide a brief description of 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 has changed at least once.
For those of you who were 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 its limitations. After the changes in JDK 7, the current JEP comes to improve this API even further and to give us the ability:
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 cases it 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 these features, so fingers crossed.
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
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 you 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 other two eyebrows to raise when you realized that the parsers you've built for the previous version had issues dealing with the current version of the JVM logging. I suppose I could continue with the reasons why it is bad, but let's concentrate on the improvements, so hopefully by the next release we will have a reason to complain that it was better before.
The gc logging seems to try to align with the other logging frameworks we might be used to, 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 tunable 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 real-time 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.
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 are to increase the manageability of these compilers:
It seems that JVM performance is targeted in the future java release, as the current JEP is intended to optimize the code cache. The goals are:
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 skipping the non-method areas - areas that should exist on the entire runtime of the JVM.
The presence of this improvement shouldn't be a surprise, but for me it is surprising that it wasn’t done 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:
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.
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 tool chain.
The first steps in the direction of project jigsaw implementation, having the intention of reorganizing the source code as modules enhancing the build tool for module building and respecting the module boundaries.
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.
As the launch 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.
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:
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:+UseCMSCollectionPassingThis JEP targets to Fix javac to properly accept and reject programs regardless of the order of importstatements and extends and implements clauses.
The increasing number of application layer protocols have been designed to 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).
It 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. It defines 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. It revises existing specifications as required to accommodate these changes.
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.
It removes 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 following blog post of the java advent series will present to you how to get involved. Imagine it like the fellowship of the ring, but target of the adventure is building java, not destroying the ring...Who might Mr. Frodo be?
This post is part of the Java Advent Calendar and it is licensed under the Creative Commons 3.0 Attribution license. If you like it, please spread the word by sharing, tweeting, FB, G+ and so on!
Java Advent calendar is an initiative from Cluj-Napoca, targeting to greet Christmas each year (since 2012) with a bunch of articles related to java or JVM. Each day, an article is published on www.javaadvent.com, in the time interval December 1st-December 24th, following a promotion on various profile sites. Currently, the pool of contributors is quite international.
Merry Christmas! We are happy to welcome you as a reader, contributor or volunteer or all of them!
by Ovidiu Mățan
