Top 10 Java Features and Enhancements

Home blog Top 10 Java Features and Enhancements
post

Top 10 Java Features and Enhancements

After Java 9 release, Java 10 came very quickly. Unlike its 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. Few of the prominent features are listed below:

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 the type of actual object created. It claims to be the only real feature for developers in JDK 10. e.g.

Time-Based Release Versioning

Starting from Java 10, Oracle has adopted the 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

Garbage Collector Interface

With the new Java version 10 update now, the code isolation of multiple garbage collectors can be improvised with the coming of the new and most common Garbage Collector Interface. Its emphasis on providing better modularity to the internal GC code which in the future, will help for adding new GC without changing existing codebase. Also helps in removing or maintaining the previous GC.

Thread – Local Handshake

A handshake operation is a callback that is executed for each Java Thread while that thread is in a safe point safe state. The callback is implemented by the VM thread while keeping the thread in a blocked state or by the thread itself. It allows executing a callback on threads without performing a global VM safe-point. It is possible and also cost-effective to stop individual threads and not just all threads or none.

Heap Allocation on Alternative Memory Devices

Applications such as in-memory databases and big data have an increasing demand for memory. Such applications could use NV-DIMM for the heap since NV-DIMMs has a larger capacity, at a lower cost, in comparison to DRAM.

Heap Allocation feature enhances the capability of HotSpot VM by allocating the Java object heap on an alternative memory device, such as an NV-DIMM as specified by the user. It also targets alternative memory devices that have the same semantics as a DRAM, including the semantics of atomic operations, and can be used instead of DRAM for the object heap to the existing application code without any change.

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.

Application Class – Data sharing

While initiating JVM, it performs some preliminary steps, one of which is loading classes in memory. If there are multiple jars having several classes, then the lag in the first request is simply visible. There arises a problem with serverless architecture, where the boot time is critical. In order to carry forward the application startup time, Application class-data sharing is used. It is to reduce footprint by sharing common class metadata across several Java processes.

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.

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

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.

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.

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.