Let's take a look and check into what is packed in Java10, which includes local variable type inference and unmodifiable collections APIs. If we check history then Java 10 is the fastest release of a Java till now. Java has always been known for slow releases, but Java 10 just trashed that concept. Java10 is a release with many future changes keeping in mind, the scope and impact of which may not be obvious but are far fetching.

Java10 features:

1. Time-Based Release Versioning (JEP 322):

From now onwards, the version-string scheme of the Java SE Platform and the JDK, and related versioning information for present and future releases have been changed due to the adoption of time-based release cycle.

The Version number is in below format:

$FEATURE.$INTERIM.$UPDATE.$PATCH

2. Local-Variable Type Inference (JEP 286):

This is one of the biggest new feature in Java 10 for developers. Type inference added to declarations of local variables with initializers. By doing this JAVA attempts to improve the developer’s experience by removing some of the strict type declarations and allowing developers to let the compiler infer the type by only using var. This can be used only in the certain scenarios as mentioned below:

• Limited only to Local Variable with the initializer
• Indexes of enhanced for loop or indexes
• Local declared in for loop

Below is the example for the same:

var list = new ArrayList<String>(); // infers ArrayList<String>  
var stream = list.stream(); // infers Stream<String>  

3. Experimental Java-Based JIT Compiler (JEP 317):

This introduces the Graal compiler research project to the JDK. A new Java-based JIT compiler which is the basis of an experimental Ahead-of-Time compiler. Graal was not directly introduced in this version, it was already added back in Java 9, but now it is possible to enable it with the following arguments.

-XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler

However, as this is in beta stage it should not be used in production.

4. Parallel Full GC for G1 (JEP 307):

G1 garbage collector was made default in JDK 9. The G1 GC behaviour is to avoid any full garbage collection which will impact the performance. Still when concurrent threads for collection cannot free the memory fast enough, users experience is impacted because of that. 

To address this problem, they made full GC parallel which improves the G1 worst-case latency considerably. They made changes to the mark-sweep-compact algorithm from G1 collector is parallelized as part of this change and will be triggered when concurrent threads for collection can’t revive the memory fast enough.

5. Application Class-Data Sharing (JEP 310):

This feature helps in improving the startup footprint, one of which is loading classes in memory, extends the existing Class-Data Sharing feature to allow application classes to be placed in the shared archive.

On starting JVM performs some preliminary steps. If there are several jars having multiple classes, then there will be a significant delay in the first request which is clearly visible. This becomes an issue with serverless architecture, where boot time is critical. In order to bring down application startup time, Application class-data sharing can be used. The idea is to reduce boot time by sharing common class metadata across different Java processes and make the loading faster.

6. Root Certificates (JEP 319):

JEP 319 will provide a default set of root Certification Authority making OpenJDK builds more appealing to developers. It also aims to reduce the difference between the OpenJDK and Oracle JDK builds. Critical security components such as TLS will now work by default in OpenJDK builds.

7. Garbage-Collector Interface (JEP 304):

This JEP increases code isolation of different garbage collectors and introduces a clean interface for garbage collectors.

This feature makes it easier to exclude a GC from a JDK build and also make it easier to add a new GC without it affecting the code base.

8. Thread-Local Handshakes (JEP 312):

This JEP lays the groundwork for improved VM performance, by making it possible to execute a callback on application threads without performing a global VM safepoint. This would mean that the JVM could stop individual threads and not just all of them. Some of the small, low-level improvements that this will enable include:

• Reducing the impact of acquiring a stack trace sample
• Better stack trace sampling
• It will improve biased locking by only stopping individual threads for revoking biases.
• Removing some memory barriers from the JVM

9. Heap Allocation on Alternative Memory Devices (JEP 316):

This enables the HotSpot VM to allocate the Java object heap on an alternative memory device, specified by the user. This new feature would, for example, make it possible in a multi-JVM environment to assign lower priority processes to use the NV-DIMM memory, and instead only allocate the higher priority processes to the DRAM.

These are some of the important Java10 features not all. Overall, it seems that Java 10 is unlikely to contain any major new features or performance improvements. This is perhaps to be expected – instead of vast change, it represents the first release in the new and gradual release cycle. If you think anything important got missed here, please let us know through comments we will be happy to update this article.