Oracle is accelerating its JDK release cycles; what does this change mean for the community?
Java is known for its sturdy version releases that arrive every few years, and each new version usually comes with a long list of features and enhancements to the platform. However, recently, Oracle decided to change this process, and accelerate the Java release cycle.
According to the company, a new JDK version will launch every 6 months and will include a smaller number of features and improvements. In the following post we’re taking a closer look at the upcoming Java version, what it will include and how shorter release cycles will affect the developers. Let’s check it out.
— OverOps (@overopshq) January 3, 2018
What Java 10 has in store for us?
We know what you’re thinking. It seems like Java 9 was just released a few weeks ago, and here we are talking about the upcoming version of the language. Java 10 will include some interesting features, such as:
Local Variable Type Inference (JEP 286)
This JEP aims to extend type inference to declarations of local variables and initializers, and Java 10 will include the identifier var that will allow defining and initializing local variables.
This will allow declarations such as:
var list = new ArrayList<String>(); // infers ArrayList<String>
var stream = list.stream(); // infers Stream<String>
If you want to understand how this JEP will affect the way you code, check out our deep dive into JEP 286.
Garbage Collectors improvements
Java 10 will include 2 JEPs that focus on improving the current Garbage Collection (GC) elements. The first one, Garbage-Collector Interface (JEP 304) wants to introduce a clean garbage collector interface, which will help improve the source code isolation of different garbage collectors.
In current Java versions there are bits and pieces of GC source files scattered all over the HotSpot sources. This becomes an issue when implementing a new garbage collector, since developers have to know where to look for those source files. One of the main goals of this JEP is to introduce better modularity for HotSpot internal GC code, have a cleaner GC interface and make it easier to implement new collectors.
The second JEP that is scheduled for Java 10 is Parallel Full GC for G1 (JEP 307), which puts its focus on improving G1 worst-case latencies, by making the full GC parallel. G1 was made the default GC in Java 9, and the goal of this JEP is to make G1 parallel as well.
Handshakes, allocation, unicode and housekeeping
Among the other features that are scheduled for Java 10, we can find:
- Thread-Local Handshakes (JEP 312) – This will introduce a new way to execute a callback on threads, so it will be both possible and cheap to stop individual threads and not just all threads or none
- Heap Allocation on Alternative Memory Devices (JEP 316) – Allowing the HotSpot VM to allocate the Java object heap on an alternative memory device, which will be specified by the user
- Additional Unicode Language-Tag Extensions (JEP 314) – The goal is to enhance java.util.Locale and its related APIs, to make it possible to implement additional unicode extensions of language tag syntax (BCP 47)
- Experimental Java-Based JIT Compiler (JEP 317) – Oracle wants to enable its Java JIT compiler, Graal, to be used as an experimental JIT compiler on the Linux/x64 platform
- Root Certificates (JEP 319) – The goal here is to open source the root certificates in Oracle’s Java SE Root Certification Authority (CA) program, making OpenJDK builds more appealing to developers. It also aims to reduce the difference between the OpenJDK and Oracle JDK builds
- Consolidate the JDK Forest into a Single Repository (JEP 296) – The main goal of this JEP is to do some housekeeping, and combine the numerous repositories of the JDK forest into a single repository
- Remove the Native-Header Generation Tool (javah) (JEP 313) – This one is plain and to the point – remove the javah tool from the JDK
There’s also one extra JEP that will be introduced in Java 10:
Time-Based Release Versioning (JEP 322)
This JEP talks about revising the version string scheme of the Java SE Platform and the JDK, as well as the related versioning information, for present and future time-based release models for some needed clarifications.
In other words, this JEP will change the way Oracle is naming their future Java versions. At first, Oracle’s announcement indicated that future Java versions would be named according to the dates in which they will be released. Meaning that the next Java version will be named Java 18.3.
This led to countless discussions and ideas for a new naming system, and Mark Reinhold proposed a Time-Based Release Versioning JEP. The existing Java naming formula contained the following elements:
- Feature – The feature release counter that will increment for every feature release, regardless of the content of the release
- Interim – Which will increment for non-feature releases that contain compatible bug fixes and enhancements but no incompatible changes, no feature removals, and no changes to standard APIs
- Update – Increments for compatible update releases that fix security issues, regressions and bugs in newer features
- Patch – For emergency releases, and will be incremented when it’s necessary to produce an emergency release to fix critical issues
Now that Java is switching to a six month release model, some changes will be made naming wise. The Feature will increment every 6 months, and the Interim will always be zero since the new release cycle will not include interim releases. However, Oracle will keep this element active to allow some flexibility for future releases. Update will increment one month after the Feature will increment, and every three months as well.
TL;DR – The March 2018 release will be named JDK 10, September 2018 release will be named JDK 11 and so on. The Update element will increment one month after the Feature element is incremented, so the April 2018 Java release will be JDK 10.0.1, July 2018 release will be named JDK 10.0.2 and so on.
Not just Java; the entire industry is moving faster
Oracle’s decision to move to a faster release cycle is part of a change we see within the entire industry. Companies, teams and even programming languages are aiming for short release cycles, constantly updating their products and staying up to date with changes and innovations that are relevant to them.
However, with faster deployments come the rise of issues and bugs within the code. After building, testing and deploying, it’s important to monitor your code and make sure everything is up and running as it should. You don’t want your customers or users to find an issue that might harm their experience with the product.
That’s why companies are building monitoring strategies that will help them cope with the move towards a continuous delivery workflow. They are doing so by using log management tools, or other tools that help them get meaningful alerts, track errors as they occur, and detect anomalies within the code. But for you to stay on top of issues in your application, you have to take your automation process one step further and utilize Automated Root Cause detection. And that’s where OverOps comes in.
With OverOps, you’ll get the complete source code and variable state across the entire call stack for every error, exception or bug, as soon as they’re introduced into the application. OverOps provides complete Automated Root Cause analysis, and helps reduce the time to identify and fix critical application errors by over 90%. This enables companies to increase application reliability, staff efficiency, agility and rate of innovation.
Want to see how easy it is to get started? Schedule a demo to find out.
The move towards a time driven model is interesting, allowing Java to keep evolving, add more features in shorter timelines and allow developers to stay updated with the latest and greatest of the language.
In his blog, Mark Reinhold wrote that Java’s current approach “made it possible to deliver big new features at a high level of quality after thorough review and testing by early adopters”. Reinhold also added that the price for this approach was that smaller APIs and JVM features could only be delivered once the major release was ready.
“For Java to remain competitive it must not just continue to move forward — it must move forward faster.”
And that’s what this new approach is all about – helping Java move faster, stay competitive in the programming landscape and still maintain its compatibility and reliability. There’s no doubt it’s an interesting move, and it’ll be even more interesting to see how Java evolves and grow at a faster pace.