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, they will 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.
Disclaimer: the list of JEPs is a moving target, since the publication of this article the list changed at least once.
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.
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/notifyAlloperations - Adaptive spin improvements and SpinPause on SPARC
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 :P.
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 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.
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.
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.
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 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.
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:
-
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 9 the following options will no longer be supported:
DefNew + CMS : -XX:-UseParNewGC -XX:+UseConcMarkSweepGCParNew + 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).
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 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 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?
This post is part of the Java Advent Calendar and 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!
JetBrains
steinhauer.software
Alexander Turner December 7, 2014
And the things I want to see are all missing. Here are real things that would have a massive benefit to Java which I doubt we will ever see:
1) Proper memory mapped files where we can map a native array (double, long etc) directly to virtual memory and so start to get realistic performance rather than be crippled by those silly buffers and 'everything wraps a ByteBuffer' we have now.
2) Real generic programming. Erasure is a silly hack which no-one likes and is a stain hard to remove from the language.
3) Deterministic memory management for key subsections.
4) True volatiles. The current volatile implementation layers 'happens before' on top of 'the compiler cannot localise this to register'. These are separate concepts and should never have been conflated. Stuff like this is why Java gets such a bad (and broadly undeserved) performance reputation.
5) Well documented and understood super scale mathematics. This is too important to leave to the compiler. We do not leave threading to the compiler, there are language constructs for that; however, we do leave super scaler computation to the compiler. However, super scalar has been in the past (up till the PC revolution) and will be in the future (with the clock speed brick wall) just as if not more important that multi-threaded programming for performance.
6) @ForceLine as a general programming attribute.
OK – probably raved enough. But, whilst the things which are slated for Java 9 are nice, they are like fiddling with the radio options on a car when the engine was designed in the nineties. We need much, much more work on the engine and less on the interior trim if Java and the JVM is to remain relevant over the next 20 years.
Olimpiu Pop December 8, 2014
yup, I totally agree with you. Another point that I don't like about the direction java is going is that a lot of things are getting deprecated by they are never removed. In my opinion a clean-up is in place and I think that erasure should erased for good from java even with the risk of breaking backwards compatibility. I am wondering whether we can't make something in this direction? Like a petition or so? 😀 gather signatures?