This post comes from my sickbed and is therefore shorter than what I’d like given the importance of 2017! 2017 is the year where Java the language, platform, ecosystem and community truly became free, with:
- Oracle open sourcing the last parts of its commercial Java.
- Java EE moving to the Eclipse Foundation.
- Eclipse Microprofile becoming a place for defacto standardisation around microservices.
- Adopt OpenJDK’s open build farm for Java itself.
- Java having a new 6 month release cycle.
- The long awaited Effective Java 3rd edition from Joshua Bloch.
Oh and of course (after some battles at the standards body) Java 9 came out as well! In case you missed the highlights of 2017, here’s some of the major happenings that occurred.
Java EE moves to Eclipse
There’s been plenty of coverage of this, but the new home for Java EE is now at Eclipse (project name EE4J, brand name TBA). See the project page for details!
Java EE is now completely open and free, including the Reference Implementations (RIs) & Technical Compatibility Kits (TCKs). This will make for a much more level playing field for the ecosystem going forwards and I expect to see a lot of innovation occurring once the hard work to do the code and IP transfer has completed.
Eclipse Microprofile for Microservices
microprofile.io is the new collaborative effort between vendors, Java User Groups and individuals to rapidly build microservice APIs that are supported by all of the major Java EE vendors, a defacto std if you will. It’s pushed out 3 releases so far and covers microservice features such as config, fault tolerance, health metrics, circuit breakers etc.
Java 6 month release cadence
Java is now going to be released every 6 months with the fist LTS release of that being Java 11 (in ~Sep 2018). This means some extra work for the tools vendors but will unshackle Java from it’s slow moving reputation. It’s certainly a massive change from the 4-5 year release cycle we’ve all been used to!
Oracle opening up Java SE
As Announced, Oracle is going to open source the remainder of its Java SE commercial features and start producing binaries of OpenJDK builds for the developer community.
Java 9 release
The 1st time around the vote for Jigsaw and the module system was a resounding No. It was a deeply complex issue but boiled down to the fact that in the form it had been represented as, Jigsaw would cause too much harm to the industry and required some small but key modifications. See the “LJC’s official position statement on this.
Mark Reinhold and Oracle to their credit, took that onboard and made the changes. The 2nd vote for Jigsaw and the module system passed through just fine. See the LJC’s official position statement on this.
Java 9 is now out and the ecosystem at large whilst adopting it slowly are making some strides in making older libraries and frameworks Java 9 compatible.
Effective Java 3rd Edition
If there’s one book you should buy this holiday period, buy this.
A view to 2018 – Java SE
Everyone of course is excited for the new features coming in Java 10:
- 286: Local-Variable Type Inference – A massive improvement to how we use switch statements, instanceofs etc today. This will make Java code more concise and clearer in its intent.
- 296: Consolidate the JDK Forest into a Single Repository – eases OpenJDK development.
- 304: Garbage-Collector Interface – Allows Shenandoah and ZGC + others to come into the platform easily.
- 307: Parallel Full GC for G1 – A much needed performance boost.
- 310: Application Class-Data Sharing – A much needed performance boost.
- 312: Thread-Local Handshakes – A pre-cursor to a lot of interesting optimizations around performance.
- 313: Remove the Native-Header Generation Tool (javah).
- 314: Additional Unicode Language-Tag Extensions.
- 316: Heap Allocation on Alternative Memory Devices – Extends where Java can run.
- 317: Experimental Java-Based JIT Compiler – Preparation for the Graal future, which will make for a Java programmable, optimizable runtime.
- 319: Root Certificates – Moar security.
- 322: Time-Based Release Versioning – Back to a sensible versioning scheme, phew!
Java 11 is a little trickier to define at this point, but the initial chunks that will make up value types will go into here.
Java’s been opened up to become what it’s truly capable of. The decisions that Oracle made in 2017 and the hard work that the community has one with Oracle to open up the last pieces of Java will make it a viable platform for the net 15-20 years.
Martijn (CEO – jClarity, Sun/Oracle Java Champion & Diabolical Developer)
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!
Author: Martijn Verburg
The Diabolical Developer, CEO – jClarity, London JUG co-leader (LJC), Speaker, Author, Javaranch Mod, PCGen & Adopt OpenJDK / A-JSR Cat herder, Java Champion
Alexander Turner December 24, 2017
I hope you get better soon!
Nice post covering a few subjects which snuck under my radar. As I spent some time dissing Java for not having ‘var’ style inference in my post, it is really nice to see it finally coming in.
However, no mention of Valhalla or Panama – will these be out in Java 11?
Do you have a feel where next Oracle will go with unsafe? I am remarkably underwhelmed by varhandles – so look on with some concerns for the future in this regard.
Thread local handshakes sound like a very good start at getting away from the safepoint issues which have dogged the horizontal scalability of the platform for so long.
Also of interest in class meta data sharing – this indicates that ‘many JVMs on one machine’ is becoming a more accepted approach. Again, in my post I discuss how this fits better with cloud computing and how startup times are key in this area. Do you see (or do you already have experience of) mapping individual JVMs to separate numa partitions?
Anyhow – get better and have a great holiday season.
Martijn Verburg December 24, 2017 — Post Author
Thanks for your comments!
Elements of Valhalla are expected in Java 11, but I’m not sure we’ll see full value types until Java 12. Panama continues to make fairly slow progress, so I’m unsure of the timelines there.
Oracle will eventually replace all of the ‘safe’ Unsafe mechanisms with explicit public APIs. The best place to comment / give feedback on those efforts will be on the openjdk mailing lists themselves (I forget which one covers the unsafe replacements, but it’s between Valhalla and Panama).
Thread local handshakes will be invaluable, it will allow diagnostic engines like our one (jClarity’s Illuminate) to profile more often with less impact..
I know Azul’s Zing has some NUMA partition mapping capabilities, but I haven’t tried it myself with Zing or Hotspot based JVMs. A good place to ask would be on the mechanical-sympathy or Friends of jclarity mailing lists!