Java10 – what is coming our way?

Java10 – what is coming our way?

Reading Time: ~ 6 minutes

Java10 is the second minor version after Java9 and it is just around the corner. What can we expect?

It seems not that long ago that Java9 came out. Indeed I only have had time to explore it now! However the next minor version, Java10, is already on the making and almost there.
Actually it is just a couple of days away, with the “General Availability” phase  being released on the 20th of March (2018).

So what can we expect from Java10?

Being a minor version there is a limited number of changes. In fact that is the idea of oracle by having a time-driven release schedule instead of feature-driven. But anyway let’s not digres and let’s go through the list of features planned:

  1. Local-Variable Type Inference
  2. Consolidate the JDK Forest into a Single Repository
  3. Garbage-Collector Interface
  4. Parallel Full GC for G1
  5. Application Class-Data Sharing
  6. Thread-Local Handshakes
  7. Remove the Native-Header Generation Tool (javah)
  8. Additional Unicode Language-Tag Extensions
  9. Heap Allocation on Alternative Memory Devices
  10. Experimental Java-Based JIT Compiler
  11. Root Certificates
  12. Time-Based Release Versioning

Local-Variable Type Inference

[JEP 286]
This is a cool one! Similar to what other languages like Kotlin, Swift, C# or Scala, just to name a few, Java will now allow (albeit in some cases only) us developers to declare a variable simply using a new keyword “var“.
The compiler will take care of doing some magic behind the curtains so that you still have that sweet static type safety.

// These
List<String> list = new ArrayList<String>();
ArrayList<String> list = new ArrayList<String>();

//Can now be written as this (will infer ArrayList<String>)
var list = new ArrayList<String>();

This is nice since it will save some typing and make the language more succint.

Wait you mentioned some limitations

Yes, yes I did. The new var keyword can not be used everywhere. Due to some, actually sound, reasoning that can be read in the JEP 286 description here is where you can make use of the var:

  • Local variables with initializers
  • Indexes in the enhanced for-loop
  • Locals declared in a traditional for-loop

that means taht in constructors parameters, lambdas, method parameters, return types and fields, you won’t be able to use it.
I personally find it ok: Writing the type is more explicit than chasing around what one passed into the function. It makes comprehension of the code much easier.

Consolidate the JDK Forest into a Single Repository

[JEP 296]
The repository of java is a mess! For java9 there were alone 8 repositories that constituted the new release.
I am pretty sure that made it quite hard to do some CI and management tasks, and apparently so did some contributors. With the Java10 release they have decided to unify everything into a single repository (although JavaFX was not part of the unification).

While this actually will make the usage of a VCS the way it meant to be, by tracking the changes to a set of files that changed due to a fix or implementation, instead of having to chase these around different repos. This change is still taking baby steps. It will have a test run with Java10, since it has only a prototype version implemented with this version, while they iron the rest of the challenges out.

This does not affect you if you are a developer using Java, but it is interesting and definitelly worth to know if you are currently or planing to contribute to the project in the future.

Garbage-Collector Interface

[JEP 304]
This improvement is looking torwards the future! The idea here is to create an interface for the GC that will allow the future GCs implementation to be based on simply one set of agreed functions and be thus easily replaceable (this smells like clean architecture if you ask me! 😉 )
This JEP does not add or remove any GC implementations but just add better support and modularity for the future.

Parallel Full GC for G1

[JEP 307]
Another Garbage collection improvement for the java10 release!
G1 was made the default garbage collector for Java9, and it is very nice however there is always some space for improvement: this one tries to improve some of the worst-case latencies of G1 by making the garbage collection fully parallel.

Application Class-Data Sharing

[JEP 310]
As described in the JEP:

Class-Data Sharing, which first appeared in Java5, allows a set of classes to be pre-processed into a shared archive file that can then be memory-mapped at runtime to reduce startup time. It can also reduce dynamic memory footprint when multiple JVMs share the same archive file.
At the moment this feature was restricted to a “set of classes”. In the scope of this JEP, the developers intended to make this widely available to the whole application.
This can improve startup time, reduce footprint of shared data and other benefits which might at first not seem visible to us but does definitely contribute to a more pleasent usage of the language.

Thread-Local Handshakes

[JEP 312]
With this new functionality it will be cheap (and possible) to stop individual threads, as opposed to the current way of doing this, which is either stopping none or all threads.
Basically what we get is a new way for threads to have callbacks executed on them. This developers dubbed this process “handshake operation”.

Remove the Native-Header Generation Tool (javah)

[JEP 313]
Make Java lighter! Eliminate unused or deprecated things!
Of course, most of the time, it is hard to decided what “unused” means. Someone around the big earth might be using that one obscure and forgotten method.
However the javah tool was superseeded by a superior functionallity contained in javac, which was added in the Java8 version, so there is no need to keep it around in Java10 anymore.
What the tool was doing was to provide the ability to write native header files at compilation time. Now javac can also do that so there is no need for 2 separate tools.

Additional Unicode Language-Tag Extensions

[JEP 314]
The goal here is to add support to the BCP47 (Best Current Practice) which in turn aims to implement a “Language-Tag” that would aid on the identification of the language used in a certain piece of information.

Heap Allocation on Alternative Memory Devices

[JEP 316]
The Java Object Heap lives in the RAM. Now with the increasing different types of memory such as NV-DIMM and other future improvements, the Heap may be looking for a new home.
This JEP talks about having the possibility for the user to choose where the allocation of the heap. This means that maybe you can buy a external memory and use it just for your program’s heap (isn’t THAT the dream?).

Small Detail

There is only two small things:
* The memory devices have to have the same semantics as DRAM (for atomic operations guarantee for example)
* All other memory structures such as code heap, metaspace, thread stacks, etc will still stay in DRAM.

Experimental Java-Based JIT Compiler

[JEP 317]
Just-in-time compilation can do a lot of cool optimizations (well sometimes it can also un-optimize the code).
With this feature they want to use the new JIT compiler “Graal” as an experimental compiler on the Linux/x64 platform instead of the standard ones (C1 and C2).

Root Certificates

[JEP 319]
This one will open source te root certificates in oracle’s Java SE CA (Certification Authority). This will (hopefully) make OpenJDK builds more attractive to developer and help to reduce the differences between those builds and the ones from Oracle JDK Build.

Time-Based Release Versioning

[JEP 322]
Soooo they are revising the way they are going to number the versions. Will that change a lot? No not really… they are mainly adding a bit more information to the whole. It will follow the following format:


which can have an abstract length. However there is a definition for the first four elements defined in the documentation:

  • $FEATURE — Incremented for every feature release regardless of release content. In a feature release there can be added or removed features, if advance notice was given at least one feature release ahead of time. Incompatible changes may be made when justified. (Formerly $MAJOR.)
  • $INTERIM — The interim-release counter, incremented for non-feature releases that contain compatible bug fixes and enhancements but no incompatible changes, no feature removals, and no changes to standard APIs. (Formerly $MINOR.)
  • $UPDATE — The update-release counter, incremented for compatible update releases that fix security issues, regressions, and bugs in newer features. (Formerly $SECURITY, but with a non-trivial incrementation rule.)
  • $PATCH — The emergency patch-release counter, incremented only when it’s necessary to produce an emergency release to fix a critical issue. (Using an additional element for this purpose minimizes disruption to both developers and users of in-flight update releases.)

And here is how they plan to update these parameters on the 6 month release cycle:
* $FEATURE is incremented every six months: The March 2018 release is JDK 10, the September 2018 release is JDK 11, and so forth.
* $INTERIM is always zero, since the six-month model does not include interim releases. We reserve it here for flexibility, so that a future revision to the release model could include such releases and say that JDK $N.1 and JDK $N.2 are compatible upgrades of JDK $N. As examples, the JDK 1.4.1 and 1.4.2 releases were, in essence, interim releases, and would have been numbered 4.1 and 4.2 under this scheme.
* $UPDATE is incremented one month after $FEATURE is incremented, and every three months thereafter: The April 2018 release is JDK 10.0.1, the July release is JDK 10.0.2, and so forth.


There are some nice little things here and there and soon we will see if they work well 😉
Did you like something in specific?
Do you have an opinion about any of the JEPs?
Leave a message

Leave your opinion, start a discussion, share an experience or just a compliment...

%d bloggers like this: