Are You Aware of Java 10 and its Features? Let me update you

Being a Java Developer I am enjoying my work more with Java 10. Are You?

Are you aware that Java 10 is here and it made the developer’s life so easy.

JDK 10 is released and that also on the scheduled time according to the official release date 20th March 2018.

You must be knowing the features added in each version and Java 9 was the recently launched version, Have a look on Java 9 features.

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

API LEVEL CHANGES IN JAVA 10:

If we talk about the libraries we have following modifications in the respective package.

Local -Variable Type Inference:

This is one of the best features added in Java 10.
Now for local variables, we can now use a specially reserved type var instead of using the primitive or actual data type.
This features reduces the boilerplate code but also has some limitations in some case.

String str1 ="Java 10";
var str2 ="Java 10";

str.getClass().getTypeName();

Here you can see that the first line declaration is the existing way and next line we have the new features.
You can verify the assignment happened to proper type or not using the getClass().getTypeName() which will give you output as java.lang.String.

If you do below incompatible assignment then it will throw compilation error:

var str= "12";

str =12;

Time-Based Release Versioning:

A new model which is Time-Based release model has been adopted in Java 10 and every 6 months major releases i.e feature releases of the Java platform will occur(Mar and Sept). The feature releases can add language features, JVM features and new Improved API’s and it can remove unwanted and deprecated old features also.

There is something called Update Release which is limited to fixes of security, bugs, and regression.

Every three years, we will have long-term release where features release will be a long-term support release and updates will be available for at least three years and it will start from September 2018.

There are Version formats that you should know:

-> FEATURE: Every release it will get incremented from the current release which is 10

->INTERIM: Every non-feature release, it will get incremented

->UPDATE: Every update releases, this will get incremented

->PATCH: This is an emergency fix for critical issues.

You can do Java Code to find your versions:

Runtime.Version versionCount = Runtime.version();

versionCount.feature() will return feature version

versionCount.interim() will return interim version

versionCount.update() will return update version

versionCount.patch() will return patch version

Garbage-Collector Interface :

This feature will introduce a clean garbage collector interface which will help us to improve the source code isolation of different garbage collectors.

The aim of introducing this features are :

-> Better modularity for the HotSpot internal GC code

-> Make is simpler to add a new GC and HotSpot without perturbing the current code base.

-> Make it 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 heap, a subclass of CollectedHeap
• BarrierSet is a class which implements the various barrier for the runtime
• Implementation of CollectorPolicy
• Implementation of GCInterpreterSupport

Parallel Full GC for G1 Dumps the Trash Efficiently :

G1 Garbage Collector was the new feature in Java 9 where it was made the default GC in place of the parallel collector which avoids any full garbage collection but when concurrent threads for collection cannot revive the memory fast enough user experiences is impacted.

The aim is to improve the G1 worst-case latencies by making the full GC parallel.

The G1 garbage collector is designed to avoid the full collections but when the concurrent collections can’t reclaim memory fast enough a fall back full GC will occur.

The implementation of full GC for G1 uses a single threaded mark-sweep-compact algorithm. We intend to parallelize the mark-sweep-compact algorithm and uses the same number of threads as the Young and Mixed Collections do. The number of threads can be controlled by the :

-XX:ParallelGCThreads option, but this will affect the number of threads used for Young and Mixed Collections.

Heap Allocation on Alternative Memory Devices:

This feature has added some control to the user, It will allow you to enable the HotSpot VM to allocate the Java Object heap on an alternative memory device, such as an NV-DIMM, specified by the user.

This aims at the alternative memory devices that have the same semantics as DRAM, including the semantics of atomic operations, and thus it can be used instead of DRAM for the object heap without any change in existing application code. All other memory structures such as the code heap, metaspace, thread stacks will continue reside in DRAM.

Consolidate the JDK Forest into a Single Repository :

We have seen that for many years, the full code base of JDK has been broken into numerous Mercurial repositories.

In JDK 9 there are eight repositories : root, corba, hotspot, jaxp, jaxws, jdk, langtools, and nashorn.

This features aims at combining 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 top-level src directory.

For example, today in the JDK forest there are modules-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

Application Class-Data Sharing Speeds Startup, Saves Memory :

This feature helps us to improve the startup and footprint, extend the existing Class-Data Sharing(“CDS”) feature to allow application classes to be placed in the shared archive.

The aim of this features are:

• Reduce the footprint by sharing common class metadata across different java processes.
• Improve the startup time
• Extends the CDS to allow archived class from the JDK’s run-time image file and the application classpath to be loaded into the built-in platform and system class loaders.
• Extend CDS to allow archived classes to be loaded into custom class loaders.

JVM while starting has some process to be followed in steps one of them is ClassLoader loads the classes in memory. If there are several jars having multiple classes, then the lag in the first request is clearly visible. This becomes an issue with the serverless architecture, while boot time is critical. In order to bring down application startup time, we can use this feature of sharing Application class-data. The idea is basically to reduce the footprint by sharing common class metadata across different java process.

To achieve this you can follow the below three steps:

-> Determine the class to archive

-> Creating the AppCDS archive

->Using the AppCDS archive

Additional Unicode Language-Tag Extensions :

The aim of this feature is to enhance the java.util.Locale and related APIs to implement the additional Unicode extension of BCP 47 language tags.

In Java 7 there was support for BCP 47 language tags added initially with the 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.

As of Java 9, the supported BCP 47 U language-tag extension are ca and nu. This JEP will add support for the following additional extensions.

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

In order to support these additional extensions, changes will be made to the following APIs:

-> java.text.DatFormat:: get*Instance will return instance based on the extension ca, rg, and/or tz.

->java.text.DateFormatSymbols::getInstance will return instances based on the extension rg

->java.text.DecimalFormatSymbols::getInstance will return instances based on the extension rg

-> java.text.NumberFormat:: get*Instance will return instance based on the extension nu and/or rg

-> java.time.format.DateTimeFormatter:: localizedBy will return DateTimeFormatter instances based on the extension ca, rg, and/or tz

-> java.time.format.DateTimeFormatterBuilder:: getLocalizedDateTimePattern will return pattern string based on the rg extension

->java.time.format.DecimalStyle::of will return DecimalStle instances based on the extensions nu, and/or rg.

->java.time.temporal.WeekFields:: of will return WeekFields instances based on the extensions fw and/or rg.

->java.util.Currency:: getInstance will return Currency instances based on the extension cu and/or rg.

->java.util.Calendar::{getFirstDayOfWeek, getMinimalDaysInWeek} will return values based on the extensions fw and/or rg.

->java.util.Locale::getDisplayName will return Currency instances based on the extension cu and/or rg.

Root Certificates:

In order to make OpenJDK builds more attractive to developers, and to reduce the differences between those builds and Oracle JDK builds, This feature provides a default set of root Certification Authority certificates in the JDK.

The cacerts keystore will be populated with a set of root certificates issued by the CAs of Oracle’s Java SE Root CA Program. As a prerequisite, each CA must sign the Oracle Contributor Agreement(OCA)

Experimental Java-Based JIT Compiler:

This feature is on the Compiler level which enables the Java-based JIT compiler, Graal, to be used as an experimental JIT compiler on the Linux/x64 platform.

Now There will a question in your mind what is Graal?

Graal, a Java Based Compiler, is the basis of the experimental Ahead-of-Time(AOT) compiler introduced in JDK 9.

Enabling it to be used as an experimental JIT compiler is one of the initiatives of Project Metropolis, and is the next step in investigating the feasibility of a Java- Based JIT for the JDK.

Graal will use the JVM compiler interface (JVMCI) introduced in JDK 9. Graal is already in the JDK, so enabling it as an experimental JIT will primarily be a testing and debugging effort.

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

-XX:+UnlockExperimentalVMOptions --XX:+UseJVMCICompiler

Thread-Local Handshakes :

This JVM feature is going the improve the performance by making it possible to execute a callback on threads without performing a global VM safepoint. Make it both possible and cheap to stop individual threads and not just all threads or none.

A handshake operation is a callback that is executed for each java Thread while that thread is in a safepoint safe state. The Callback is executed either by the thread itself or by the VM thread while keeping the thread is a blocked state.

The big difference between safepointing and handshaking is that the per-thread operation will be performed on all threads as soon as possible and they will continue to execute as soon as its own operation is completed. If a Java Thread is known to be running, then a handshake can be performed with that single Java Thread as well.

There are multiple applications when we stop individual threads :

• Improving biased lock revocation to only stop individual threads for revoking biases, rather than all of them.
• Reducing the overall VM latency impact of different types of serviceability queries such as acquiring stack traces for all threads which on a VM with a large number of Java Threads can be a slow operation.
• Performing safer stack trace sampling by reducing reliance on signals.

Remove the Native-Header Generation Tool :

In Java  8 they added a tool functionality which provides the ability to write native header files at the compile time, thereby eliminating the need for a separate tool.

Focussing on the support provided by javac eliminates the need to upgrade javah to support recent new paradigms, such as API access via the Compiler API in javax.tools.*, or the new java.util.spi.ToolProvider added in JDK 9.

Now they are removing the javah tool from the JDK

Hope So I have covered most of the features introduced in JAVA 10, If there is something missing then please add in the comment section it will be really helpful.

Till Then Stay tuned to this blog, we are coming up with more technical stuff.

Amit

Amit is a software developer by profession. He is passionate about all the technologies which can be used to build an application like java related technologies and many more and loves to implement it his career or for knowledge purpose and share his experience with you all. To know more see the About me profile.