By Olimpiu Pop
As everybody knows, winter (especially the time before Christmas) is a time for wishing and hoping – a moment when dreams seem to be tangible. A time when children (and some adults) create fictional or real letters to Santa Claus, hoping their fantasies will become reality…This is actually quite timely, as even the people behind OpenJDK expressed their wishes for Java on the first day of December when they published an updated list of JEPs. Hold on though, don’t get excited just yet…as we know from bitter experience, these hopes might become reality somewhere in early 2016. Or at least this is the plan, and history has showed us what sticking to a plan means :). Of course, the presence of a JEP doesn’t mean that the final release will necessarily contain it – as the JEP process diagram clearly explains. But for the sake of winter fairytales, we will go through the list and provide a brief description of what the intended purpose for each item is.
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.
- Get/set the process name of the current Java virtual machine and processes created with the existing API (where possible).
- Enumerate Java virtual machines and processes on the system. Information on each process may include its pid, name, state, and perhaps resource usage.
- Deal with process trees, in particular some means to destroy a process tree.
- 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.
I had the luck and pleasure to be present at a performance workshop the other day with Peter Lawrey, and one of the thumb rules of Java performance tuning was thus: 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.
The title kind of says it all! If you are working with enterprise applications, you will have 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 have issues dealing with the current version of the JVM logging. I suppose I can continue with why this is bad, but let’s concentrate on the improvements – 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.
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 goal of this JEP is to increase the manageability of these compilers with:
- 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.
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 these 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 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 compared 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.
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.
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 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 JEP 212 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 to the Java language – some snazzy new clothes for 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 contributed 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.
Spring time cleaning continues with the removal of the JVM flags deprecated in Java 8 release, so with release of Java 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
This 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 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.
As the HTML standard version reached version 5, the Javadoc pages of the JDK need to keep up the pace as well, hence the upgrade from HTML 4.01.
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 a little blue,but after reading more into it I became rather excited as it seems that Java is yet again to start on the road for another adventure – and Oracle need all the help they could get. So if you want to get involved (and please do!) , a later blog post of the Java advent series will present you how to do this. Imagine it like the Fellowship of the ring, but the target of the adventure is building Java not – destroying the ring…who might Frodo be?