Java 10 Features and Enhancements

After Java 9 release, Java 10 came very quickly. Unlike it’s previous release, Java 10 does not have that many exciting features, still it has few important updates which will change the way you code, and other future Java versions.

Table of Contents

JEP 286: Local Variable Type Inference
JEP 322: Time-Based Release Versioning
JEP 304: Garbage-Collector Interface
JEP 307: Parallel Full GC for G1
JEP 316: Heap Allocation on Alternative Memory Devices
JEP 296: Consolidate the JDK Forest into a Single Repository
JEP 310: Application Class-Data Sharing
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
New Added APIs and Options
Removed APIs and Options

JEP 286: Local Variable Type Inference

Java has now var style declarations. It allows you to declare a local variable without specifying its type. The type of variable will be inferred from type of actual object created. It claims to be the only real feature for developers in JDK 10. e.g.

var str = "Hello world";
 
//or
 
String str = "Hello world";

In above example, both statements are equivalent. In first statement, type of str is determined by type of assignment which of String type.

Read More: Java var – Local-Variable Type Inference

JEP 322: Time-Based Release Versioning

Starting from Java 10, Oracle has adapted time based version-string scheme. The new format of the version number is:

$FEATURE.$INTERIM.$UPDATE.$PATCH

Unlike the old releases, the new time-based releases will not be delayed and features will be released every six months, with no constraints on what features can go out in the releases.

There are Long Term Releases (LTS) as well. It is mainly for enterprise customers. LTS version of the products will offer premier and sustained support from Oracle and it will be targeted every 3 years. Also, updates for these releases will be available for at least three years.

Read More: Java Version – Time-Based Release Versioning

JEP 304: Garbage-Collector Interface

In earlier JDK structure, the components that made up a Garbage Collector (GC) implementation were scattered throughout various parts of the code base. It’s changed in Java 10. Now, it is a clean interface within the JVM source code to allow alternative collectors to be quickly and easily integrated. It will improve source-code isolation of different garbage collectors.

This is purely refactoring. Everything that worked before needs to work afterwards, and performance should not regress.

JEP 307: Parallel Full GC for G1

Java 9 introduced G1 (garbage first) garbage collector. The G1 garbage collector is designed to avoid full collections, but when the concurrent collections can’t reclaim memory fast enough. With this change, a fall back full GC will occur.

The current implementation of the full GC for G1 uses a single threaded mark-sweep-compact algorithm. This change will parallelize the mark-sweep-compact algorithm and use the same number of threads. It will be triggered when concurrent threads for collection can’t revive the memory fast enough.

The number of threads can be controlled by the -XX:ParallelGCThreads option.

JEP 316: Heap Allocation on Alternative Memory Devices

The goal of this change is 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.

To allocate the heap in such memory we can add a new option, -XX:AllocateHeapAt=<path>. This option would take a path to the file system and use memory mapping to achieve the desired result of allocating the object heap on the memory device. The existing heap related flags such as -Xmx, -Xms, etc., and garbage-collection related flags would continue to work as before.

JEP 296: Consolidate the JDK Forest into a Single Repository

As part of this change numerous repositories of the JDK forest is combined into a single repository in order to simplify and streamline development.

In JDK 9 there are eight repos: root, corba, hotspot, jaxp, jaxws, jdk, langtools, and nashorn. 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 310: Application Class-Data Sharing

The goal of this feature is to improve the startup footprint, extends the existing Class-Data Sharing (“CDS”) feature to allow application classes to be placed in the shared archive.

Class-Data Sharing, introduced in JDK 5, 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.

Currently CDS only allows the bootstrap class loader to load archived classes. Application CDS allows the built-in system class loader, the built-in platform class loader, and custom class loaders to load archived classes.

Specify the -XX:+UseAppCDS command-line option to enable class data sharing for the system class loader, the platform class loader, and other user-defined class loaders.

JEP 314: Additional Unicode Language-Tag Extensions

It’s goal is to enhance java.util.Locale and related APIs to implement additional Unicode extensions of BCP 47 language tags. Support for BCP 47 language tags was 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)

Related APIs which got modified are:

java.text.DateFormat::get*Instance
java.text.DateFormatSymbols::getInstance
java.text.DecimalFormatSymbols::getInstance
java.text.NumberFormat::get*Instance
java.time.format.DateTimeFormatter::localizedBy
java.time.format.DateTimeFormatterBuilder::getLocalizedDateTimePattern
java.time.format.DecimalStyle::of
java.time.temporal.WeekFields::of
java.util.Calendar::{getFirstDayOfWeek,getMinimalDaysInWeek}
java.util.Currency::getInstance
java.util.Locale::getDisplayName
java.util.spi.LocaleNameProvider

JEP 319: Root Certificates

The cacerts keystore, which is part of the JDK, is intended to contain a set of root certificates that can be used to establish trust in the certificate chains employed in various security protocols. The cacerts keystore in the JDK source code, however, is currently empty.

The cacerts keystore will be populated with a set of root certificates issued by the CAs of Oracle’s Java SE Root CA Program. A lot of vendors have already signed to the required agreement and, for each, a list of the root certificates that will be included. Those that do not sign an agreement will not be included at this time. Those that take longer to process will be included in the next release.

This will also mean that both Oracle & Open JDK binaries will be functionally the same. Critical security components such as TLS will work by default in OpenJDK builds going forward.

JEP 317: Experimental Java-Based JIT Compiler

This feature enables the Java-based JIT compiler, Graal, to be used as an experimental JIT compiler on the Linux/x64 platform. 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

Graal is a complete rewrite of the JIT compiler in Java from scratch. Previous JIT complier was written in C++.

JEP 312: Thread-Local Handshakes

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.

Thread-local handshakes will be implemented initially on x64 and SPARC. Other platforms will fall back to normal safepoints. A new product option, -XX:ThreadLocalHandshakes (default value true), allows users to select normal safepoints on supported platforms.

JEP 313: Remove the Native-Header Generation Tool

It will remove the javah tool from the JDK, a separate tool to generate header files when compiling JNI code, as this can be done through javac.

This is another Java 10 feature which focuses on housekeeping.

New Added APIs and Options

73 new API’s has been added in Java 10. Let’s go through few of them:

API Description
Optional.orElseThrow() A new method orElseThrow has been added to the Optional class. It is synonymous with and is now the preferred alternative to the existing get method.
List.copyOf, Set.copyOf, and Map.copyOf These methods create new collection instances from existing instances.
Collectors.toUnmodifiableList, Collectors.toUnmodifiableSet, Collectors.toUnmodifiableMap These methods allow the elements of a Stream to be collected into an unmodifiable collection
--jdk.disableLastUsageTracking To disable JRE last usage tracking for a running VM.
--add-stylesheet Provides support for the use of multiple stylesheets in the generated documentation.
--main-stylesheet To help distinguish the main stylesheet from any additional stylesheets.
@summary Tag Added to explicitly specify the text used as the summary of the API description. By default, the summary of an API description is inferred from the first sentence.

Removed APIs and Options

API Description
LookAndFeels
Runtime.getLocalizedInputStream, Runtime.getLocalizedOutputStream Part of an obsolete internationalization mechanism and have no known uses.
RMI Server-Side Multiplex Protocol Support It was disabled in JDK 9 and, now, has been removed.
Common DOM APIs The com.sun.java.browser.plugin2.DOM, and sun.plugin.dom.DOMObject APIs have been removed. Applications can use netscape.javascript.JSObject to manipulate the DOM.
FlatProfiler Deprecated in JDK 9, has been made obsolete by removing the implementation code.
-Xoss, -Xsqnopause, -Xoptimize, -Xboundthreads, and -Xusealtsigs Options removed.
policytool The policytool security tool has been removed from the JDK.
Deprecated Classes in com.sun.security.auth.** Following classes are removed now.

  • com.sun.security.auth.PolicyFile
  • com.sun.security.auth.SolarisNumericGroupPrincipal
  • com.sun.security.auth.SolarisNumericUserPrincipal
  • com.sun.security.auth.SolarisPrincipal
  • com.sun.security.auth.X500Principal
  • com.sun.security.auth.module.SolarisLoginModule
  • com.sun.security.auth.module.SolarisSystem

Overall, Java 10 has many features we may not use in everyday programming but it still has many features which work behind the scene to make it important milestone.

Happy Learning !!

Comments

Subscribe
Notify of
guest
2 Comments
Most Voted
Newest Oldest
Inline Feedbacks
View all comments

About Us

HowToDoInJava provides tutorials and how-to guides on Java and related technologies.

It also shares the best practices, algorithms & solutions and frequently asked interview questions.

Our Blogs

REST API Tutorial

Dark Mode

Dark Mode