Java 10 New Added Features and Improvements

In this article of Java 10 New Added Features and Improvements, Java 10 has been initially released on 20 March 2018 with the several new features and improvements. After the release of Java 9, Java 10 was quick to be part of the Java family. But unlike its predecessors, Java 10 does not offer as many exciting new features like Java 8 and 9 did. Still, it has a few important features that may change your coding habits and affect the upcoming Java versions.

Java 10 New Added Features

Java 10 New Added Features and Improvements

Open JDK 10 was released with twelve features as the following:

JEP 286: Local-Variable Type Inference
JEP 296: Consolidate the JDK Forest into a Single Repository
JEP 304: Garbage-Collector Interface
JEP 307: Parallel Full GC for G1
JEP 310: Application Class-Data Sharing
JEP 312: Thread-Local Handshakes
JEP 313: Remove the Native-Header Generation Tool
JEP 314: Additional Unicode Language-Tag Extensions
JEP 316: Heap Allocation on Alternative Memory Devices
JEP 317: Experimental Java-Based JIT Compiler
JEP 319: Root Certificates
JEP 322: Time-Based Release Versioning

JEP 286: Local Variable Type Inference

Java now offers var way of declarations. It enables users to project a local variable. This variable might not have a type defined. The type of a variable may be taken from the type of the actual object being introduced. It is said to be the stand-alone real feature for Java developers in the Java 10 release.

For reference, see the example below.

var str = "Welcome to Dineshonjava";
//or
String str = "Welcome to Dineshonjava";

In this case, the statements would be considered equivalent. The type of str is taken from the assignment of String.

Consolidate the JDK Forest into a Single Repository

Combine the numerous repositories of the JDK forest into a single repository in order to simplify and streamline development.

In the consolidated forests, code for Java modules is generally combined under a single top-level src directory. For example, today in the JDK forest there are module-based directories like

$ROOT/jdk/src/java.base
...
$ROOT/langtools/src/java.compiler
...

In the consolidated forest, this code is instead organized as

$ROOT/src/java.base
$ROOT/src/java.compiler
...

JEP 304: Garbage-Collector Interface

In the earlier Java releases, the parts that conclude the entirety of a Garbage Collector implementation were spread throughout different pieces of the code base and not accommodated in one single place. Java 10 brought that very important change in the JDK structure. With recent changes, it is a neat interface inside the Java Virtual Machine code to enable easy and quick integration of collectors. It will improvise the source-code separation of various garbage collectors.

JEP 307: Parallel Full GC for G1

Java 9 introduced G1 garbage collector. This garbage collector is made to ignore full collections, however, while the concurrent collections can’t get memory quickly, by this alteration, a fall back full GC will take place.

The recent execution of the full Garbage Collector for G1 utilizes a single mark-sweep-compact algorithm. This difference will align itself with the mark-sweep-compact algorithm and makes use of the exact count of threads. It gets triggered right while the concurrent threads for collection couldn’t run fast enough to revitalize the memory.

The count of threads can be improvised and changed by the -XX: ParallelGCThreads option.

JEP 310: Application Class-Data Sharing

The objective of this particular option is to improvise the startup footprint, extend the already introduced Class-Data Sharing (“CDS”) option to enable the application classes to be saved within the shared archive.

Class-Data Sharing, first introduced in Java 5, allowed a bunch of classes to be processed in advance into a shared archive file that could be memory-mapped during the runtime to decrease startup time. When various JVM share the same file archive, it results in reduced dynamic memory.

The only bootstrap class loader is currently able to load the classed that are archived. With Application CDS built-in system class loader, the built-in platform class loader, and custom class loaders are able to load the classes that are archived.

JEP 312: Thread-Local Handshakes

This JEP sets the basis for better VM performance without making use of Globa VM and executes the application thread. This implicates that the JVM could halt single threads but not all of them.

Thread-local handshakes will be executed and effectuated in starting on x64 and SPARC. While all other platforms do set back to safe platforms. The latest product option called XX:ThreadLocalHandshakes (default value true), let’s coders to choose normal safe points on supported platforms.

JEP 313: Remove the Native-Header Generation Tool

Remove the javah tool from the JDK. There are no direct JDK dependences on the javah tool. Externally, there are some derivatives of javah, such as the Ant javah task, but just as users of the javah command are recommended to use javac.

JEP 314: Additional Unicode Language-Tag Extensions

In this feature, Java 10 enhances java.util.Locale and related APIs to implement additional Unicode extensions of BCP 47 language tags. Support for BCP 47 language tags was initially added in Java SE 7, with support for the Unicode locale extension limited to calendars and numbers. This JEP will implement more of the extensions specified in the latest LDML specification, in the relevant JDK classes.

This JEP will add support for the following additional extensions:

  • cu (currency type)
  • fw (first day of week)
  • rg (region override)
  • tz (time zone)

Changed APIs in Java 10 as the following:

  • java.text.DateFormat
  • java.text.DateFormatSymbols
  • java.text.DecimalFormatSymbols
  • java.text.NumberFormat
  • java.time.format.DateTimeFormatter
  • java.time.format.DateTimeFormatterBuilder
  • java.time.format.DecimalStyle
  • java.time.temporal.WeekFields
  • java.util.Calendar
  • java.util.Currency
  • java.util.Locale
  • java.util.spi.LocaleNameProvider

JEP 316: Heap Allocation on Alternative Memory Devices

The objective of this particular option is to turn on the HotSpot VM to assign the Java object heap on another memory device, such as an NV-DIMM.

We can find a new dumping space for heap in such memory by adding the latest consideration: XX:AllocateHeapAt=. A way to the file system could be taken through this particular option and utilize the memory mapping to get the expected output of allocating the object. The heap related flags that already exist such as -Xmx, -Xms, etc. GC relevant flags would keep working like earlier.

JEP 317: Experimental Java-Based JIT Compiler

Enable the Java-based JIT compiler, Graal, to be used as an experimental JIT compiler on the Linux/x64 platform.
Graal is a complete rewrite of the JIT compiler in Java from scratch. Previous JIT compiler was written in C++.

To enable Graal as the JIT compiler, use the following options on the java command line:

-XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler

JEP 319: Root Certificates

The cacerts keystore, that is a component of the Java programme, has root certificates that are used to build trust in certificate chains working in many security protocols. At the moment it is empty, and can only be populated with a root certificate supplied by the CAs of Oracle’s Java SE Root CA Program. A great number of vendors have accepted the terms and have signed the agreement. Hence, this means that both Oracle & Open JDK binaries would also be technically one or the same. Important security components like Transport Layer Security will operate by default in OpenJDK builds in future.

JEP 322: Time-Based Release Versioning

Since the release of Java 10, Oracle has used a time-dependent version-string scheme. Here is the format of the version number:

$FEATURE.$INTERIM.$UPDATE.$PATCH

As compared to the earlier releases, the recent time-dependent releases won’t be faster and features will be released within a period of half a year with no objections or alterations on which features can and cannot be released.

The Long-Term releases are majorly for enterprise customers. This version of the products now offers a long time support from Oracle for a period of three years as a whole. The new updates will roll out keeping the duration of three months in consideration.

New Added APIs in Open JDK 10

There are 73 new API’s added to the Java 10 release. And although to the user interface Java 10 might not be a huge step towards programme advancement, the features that work behind the screen have had vast improvements after the release of Java 10.