New features in Java 10

Recently Oracle has announced the general availability of new features in Java 10 (JDK 10) on Mar 20, 2018. We can download Production-ready binaries of JDK 10 under the GPL from:

  1. Oracle [ ]
  2. OpenJDK [ ]

Oracle has now shifted to a 6 months’ release pattern. Therefore, users will not be getting free LTS (long term support) anymore. In order to get free updates regularly, you need to switch to the new release immediately. We will now be having new versions released every 6 months, with JDK 11 scheduled to be released in Sep 2018. One more surprise, Oracle Java LTS releases may not be free anymore.

The release cycle will have 2 public updates. First update will be after one month of the release and the second update will be after three months. Also, Oracle will be finally stop providing its JDK for free use. Java 10.0.2 will be released in July 2018 which will be the last free JDK from Oracle. After that, you need to either pay Oracle or use OpenJDK.

The biggest change seen in Java 10 is the New Java Local Variable Type. This change was awaited by the Java developers and will help in improving the developer experience.

Now let us take a look at the new features in JDK 10 (referred as JEPs).

1. Local-Variable Type Inference

Java is a type language. Every variable and value must have a type. The type compatibility must have checked on compile time as well as runtime.

In JDK 10 we can declare a local variable without specifying its type, just using by var.

See the example below:


Java 10 var feature

This is called type inferring means Java know the type by expression result assigned to the variable, so no need of boiler-plate code for local variable initialization and it increases code readability, seems good!

Some Important points about “var”:

  • The identifier var is not a keyword or reserved word, it is reserved type name. So what is reserved type name means? It means any developer can use var as name of variable, method and/or package name but cannot use as class/interface name.
  • In case of variable only local variable like:
    • Local variables declared in method body.
    • Indexes in the enhanced for-loop, and locals declared in a traditional for-loop.
  • Where we cannot use var as local variable:
    • Formal parameters of method.
    • Formal parameters of constructor.
    • Formal parameters of catch block.
    • Return type of a method

For more details, you can refer to JEP286.

2. Consolidate the JDK Forest into a Single Repository

JDK preserve their code in multiple numerous repositories. In JDK 9 there are eight repos:

  1. root
  2. corba
  3. hotspot
  4. jaxp
  5. jaxws
  6. jdk
  7. langtools
  8. nashorn

JDK forest combined all multiple repos into a single repository in order to simplify and streamline development.

Model of multiple repos has many downsides and does a poor job of supporting various desirable source-code management operations.

In particular, it is not possible to perform an atomic commit across repositories of inter-dependent changesets. For example, if the code for a single bug fix or RFE spans both the jdk and hotspot repos today, the change to both repositories cannot be done atomically.

For more details, you can refer to JEP296.

3. Remove the Native-Header Generation Tool (javah)

javah tool is no more in JDK 10, yes the javah tool is removed from the JDK10. This has been removed as it has been already replaced by the functionality in javac, which was added in JDK8 itself.

Javah was required to write the corresponding native header files when the Java source code gets compiled. Now, javac provides this functionality and thus there is no need of javah tool required for the same.

Therefore, the native header can be generated now using the Java complier with –h option.

On java Se 8(As I preinstalled it):

Java 8 javah

 On java SE 10:

Java 10 javah

For more details, you can refer to JEP313.

4. Garbage-Collector Interface

This will improve the source code isolation of different garbage collectors by introducing a clean garbage collector (GC) interface. Thus it will have a better modularity for HotSpot internal GC code.

Due to code modularity it is easier to exclude a GC from a JDK build.

The GC interface would be defined by the existing class CollectedHeap which every garbage collector needs to implement. The CollectedHeap class would drive most aspects of interaction between the garbage collector and the rest of HotSpot.

For more details, you can refer to JEP304.

5. Parallel Full GC for G1

This feature improves G1 worst-case latencies by making the full GC parallel.

The G1 garbage collector was made the default in JDK 9. The previous default, the parallel collector, has a parallel full GC. To minimize the impact for users experiencing full GCs, the G1 full GC should be made parallel as well.

For more details, you can refer to JEP307.

6. Application Class-Data Sharing

Class-Data Sharing (CDS) first introduced in Jdk5 for improving JVM startup time.

In JDK 10, this feature is enhanced by allowing the built-in system class loader, the built-in platform class loader, and custom class loaders to load shared archived classes.

For more details, you can refer to JEP310.

7. Thread-Local Handshakes

This is very low-level JVM change.

This feature makes JDK10 both cheap and possible to stop individual threads instead of all or none thread(s).

For more details, you can refer to JEP312.

8. Heap Allocation on Alternative Memory Devices.

With the evolution of time, both software and hardware get evolves rapidly.

In JDK 10, now it possible to use non-volatile RAM with same interface along similar performance characteristics to conventional DRAM

With the availability of cheap NV-DIMM memory, future systems may be equipped with heterogeneous memory architectures. One example of such technology is Intel’s 3D XPoint.

This features enables the HotSpot VM to allocate the Java object heap on an alternative memory device, such as an NV-DIMM, specified by the user.

For more details, you can refer to JEP316.

9. Experimental Java-Based JIT Compiler

This JEP says that a larger part of JVM will rewritten in Java, Currently it in in C++. This feature enables the Java-based JIT compiler named Graal (compiler research project).

It is used experimentally on the Linux/x64 platform. It will not beat the performance of the existing JIT compilers.

For more details, you can refer to JEP317.


10. Root Certificates

Some security components like TLS now work by default in OpenJDK builds due to default Root Certificate.

This is a beneficial add-on and is probably will become the part of the work Oracle is undertaking to ensure that OpenJDK binaries and Oracle JDK binaries are functionally the same.

Open-source the root certificates in Oracle’s Java SE Root CA program in order to make OpenJDK builds more attractive to developers, and to reduce the differences between those builds and Oracle JDK builds.

For more details, you can refer to JEP319.

11. APIs for Creating Unmodifiable Collections

This is one of the smaller improvements but worth a mention.

New methods added in Java 10 to create unmodifiable collections. The methods that were added in Java 9 were really helpful.

  1. List.copyOf,
  2. Set.copyOf,
  3. Map.copyOf
  4. Collectors.toUnmodifiableList
  5. Collectors.toUnmodifiableSet,
  6. Collectors.toUnmodifiableMap

12. Byte Code Generation for Enhanced For Loops

A bug fix that was done for enhanced for loop. If a big list was used by a enhanced for loop and the list was not used after the loop, setting the list to null had no effect. It has been fixed now by setting the temporary variables used by for loop to null. The fix is somewhat like below.


Overall Java 10 has focused on representing first release instead of making vast changes. So, it will have a more frequent release cycle every 6 months and this release contains Local variable type interface (JEP286) as a major change.

I hope you find the new Java 10 release useful. Please let us know your suggestions in comments.

Leave a Reply