After Java 9 release, Java 10 came very quickly. Unlike it’s previous release, Java 10 does not have many exciting features, still it has few important updates which will change the way you code.
Novelties’ in Java 10
- Local-variable type Inference
- Root Certificates for OpenJDK
- Change in Java garbage collecting
- Garbage collector interface
- Experimental Java-based JIT compiler
- Heap allocation on alternative memory devices
- Application class-data sharing
- Consolidating the JDK Forest into a Single Repository
Local Variable Type Inference:
Now java has var style declaration. It allows you to declare a local variable without specifying its type.
Usage Restricted to:
- Local variables with initializers.
- Indexes in the enhanced for loop.
- Locals declared in a traditional for loop.
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.
Change in Java Garbage Collecting:
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.
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.
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 safe points. Performing safer stack traces.
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.
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.
Consolidating the JDK Forest into a Single Repository:
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.
Splitting up the large applications. It also allows application to be “aware” of their docker.
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.