1. Jose Marcano, Sr. Software Engineer, May 15, 2018
Java 10–changes to JDK 10.
Jose Marcano, Sr. Software Engineer, May 15, 2018

2. Java biggest changes Java 5 generics Java 7 GC1/NIO.
Java 8 Lambdas/Streams
Java 9 Modules.

3. JEP and JSR Definition JEP JSR JDK Enhancement Proposal
Java Specification Request

4. Java 10 changes 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 (javah)
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

5. JEP-286 var
Local variable type inference, to enhance the Java language to extend type inference to declarations of local variables with initializers.
Before Java 10:
List<String> list = new ArrayList<String>(); URL url = new URL("
URLConnection conn = url.openConnection();
Reader reader = new BufferedReader( new InputStreamReader(conn.getInputStream()));
Java 10:
var list = new ArrayList<String>(); var url = new URL("
var conn = url.openConnection();
var reader = new BufferedReader( new InputStreamReader(conn.getInputStream()));

6. JEP-286 var
Local variable type inference, to enhance the Java language to extend type inference to declarations of local variables with initializers.
List<String> list = new ArrayList<>(); To
var list = new ArrayList<>();
Is list a List<String> ? No it is a List<Object>

7. JEP-286 var The var will be restricted to:
Local variables with initializers
Indexes in the enhanced for-loop
Locals declared in a traditional for-loop
It will not be available for:
Method parameters
Constructor parameters
Method return types
Fields
Catch formals (or any other kind of variable declaration)

8. JEP-296: Consolidate the JDK Forest into a Single Repository
 In JDK 9 there are eight repos: root, corba, hotspot, jaxp, jaxws, jdk, langtools, and nashorn.
The idea is to combine many repositories of the JDK forest into a single repository to simplify development.

9. JEP-304: Garbage-Collector Interface
Improve the source code isolation of different garbage collectors by introducing a clean garbage collector (GC) interface
Better modularity for HotSpot internal GC code
Make it simpler to add a new GC to HotSpot without perturbing the current code base
Make it easier to exclude a GC from a JDK build

10. JEP-307: Parallel Full GC for G1
G1 became the default garbage collector in JDK 9. Its design tries to avoid full GC
G1 only uses a single-threaded mark-sweep-compact algorithm to perform a full collection
The previous default, the parallel collector, has a parallel full GC To minimize the impact for users experiencing full GCs, the G1 full GC should be made parallel as well
The number of threads can be controlled by the -XX:ParallelGCThreads option
Improve G1 worst-case latencies

11. JEP-310: Application Class-Data Sharing
Introduced in JDK 5
To improve startup and footprint, this JEP extends the existing Class-Data Sharing ("CDS") feature to allow application classes to be placed in the shared archive
Until Java 10, it was only possible to use CDS with  bootstrap class loader.
Java 10 enables CDS for system / application class loader with -XX:+UseAppCDS option

12. JEP-312: Thread-Local Handshakes
 Introduce a way to execute a callback on threads without performing a global VM safepoint
Makes 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 JavaThread while that thread is in a safepoint safe state
Thread-local handshakes will be implemented initially on x64 and SPARC. Other platforms will fall back to normal safepoints.

13. JEP-312: Thread-Local Handshakes
 what’s a safepoint?
Stop-the-World pause mechanism
Stopping all threads are required to ensure that safepoint initiator has exclusive access to JVM data structure and can perform certain operations.
When a safepoint call is issued all of the application threads should "come to safepoint" as fast as possible.
Threads that have come to safepoint block until the JVM releases them

14. JEP-312: Thread-Local Handshakes
When safepoints are used?
Garbage collection pauses
Flushing code cache
Class redefinition (e.g. hot swap or instrumentation)
Biased lock revocation
Various debug operation (e.g. deadlock check or stack trace dump)

15. JEP-313: Remove the Native-Header Generation Tool (javah)
Remove the javah tool from the JDK since it has been superseded by superior functionality in javac.

16. JEP-314: Additional Unicode Language-Tag Extensions
Additional Unicode Language-Tag Extensions: Enhances java.util.Locale and related APIs to implement additional Unicode extensions of BCP 47 language tags.
As of Java SE 9, the supported BCP 47 U language-tag extensions 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)

17. JEP-314: Additional Unicode Language-Tag Extensions
Additional Unicode Language-Tag Extensions: Enhances java.util.Locale and related APIs to implement additional Unicode extensions of BCP 47 language tags.
As of Java SE 9, the supported BCP 47 U language-tag extensions 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)

18. JEP-314: Additional Unicode Language-Tag Extensions
jshell> Currency.getInstance(Locale.forLanguageTag("de-CH")).getSymbol() $22 ==> "CHF“
jshell> Currency.getInstance(Locale.forLanguageTag("de-CH-u-cu-usd")).getSymbol() $25 ==> "$"

19. JEP-316: Heap Allocation on Alternative Memory Devices
Enables the HotSpot VM to allocate the Java object heap on an alternative memory device, such as an NV-DIMM, specified by the user.

20. JEP-316: Heap Allocation on Alternative Memory Devices
Some use cases for this proposal are:
In multi-JVM deployments some JVMs such as daemons, services, etc., have lower priority than others. NV-DIMMs would potentially have higher access latency compared to DRAM. Low-priority processes can use NV-DIMM memory for the heap, allowing high-priority processes to use more DRAM.
Applications such as big data and in-memory databases have an ever-increasing demand for memory. Such applications could use NV-DIMM for the heap since NV-DIMMs would potentially have a larger capacity, at lower cost, compared to DRAM.

21. JEP-316: Heap Allocation on Alternative Memory Devices
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 JEP does not intend to share a non-volatile region between multiple running JVMs or re-use the same region for further invocations of the JVM.
The existing heap related flags such as -Xmx, -Xms, etc., and garbage-collection related flags would continue to work as before.

22. JEP-317: Experimental Java-Based JIT Compiler
Enables the Java-based JIT compiler, Graal, to be used as an experimental JIT compiler on the Linux/x64 platform
Graal, is the basis of the experimental Ahead-of-Time (AOT) compiler introduced in JDK 9
To enable Graal as the JIT compiler, use the following options on the java command line:
-XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler

23. JEP-319: Root Certificates
Provides a default set of root Certification Authority (CA) certificates in the JDK.
Open-source the root certificates in Oracle's Java SE Root CA program in order to make OpenJDK builds more attractive to developers, and to reduce the differences between those builds and Oracle JDK builds.

24. JEP-319: Root Certificates
Provides a default set of root Certification Authority (CA) certificates in the JDK.
Open-source the root certificates in Oracle's Java SE Root CA program in order to make OpenJDK builds more attractive to developers, and to reduce the differences between those builds and Oracle JDK builds.

25. JEP-322: Time-Based Release Versioning
Revises the version-string scheme of the Java SE Platform and the JDK, and related versioning information, for present and future time-based release models.
The version-string scheme introduced by JEP 223 was a significant improvement over that of the past. That scheme is not, however, well-suited to the future, in which we intend to ship new releases of the Java SE Platform and the JDK on a strict, six-month cadence.

26. JEP-322: Time-Based Release Versioning
Under the six-month release model the elements of version numbers vary as follows:
$FEATURE is incremented every six months: The March 2018 release is JDK 10, the September 2018 release is JDK 11, and so forth.
$INTERIM is always zero, since the six-month model does not include interim releases. We reserve it here for flexibility, so that a future revision to the release model could include such releases

27. JEP-322: Time-Based Release Versioning
$UPDATE is incremented one month after $FEATURE is incremented, and every three months thereafter: The April 2018 release is JDK , the July release is JDK , and so forth.
$PATCH — The emergency patch-release counter, incremented only when it's necessary to produce an emergency release to fix a critical issue

28. Java Improvements for Docker Containers
JDK  Improve docker container detection and resource configuration usage
The JVM has been modified to be aware that it is running in a Docker container and will extract container specific configuration information instead of querying the operating system
The information being extracted is the number of CPUs and total memory that have been allocated to the container. The total number of CPUs available to the Java process is calculated from any specified cpu sets, cpu shares or cpu quotas.

29. Java Improvements for Docker Containers
JDK  Improve docker container detection and resource configuration usage
This support is only available on Linux-based platforms. This new support is enabled by default and can be disabled in the command line with the JVM option:
-XX:-UseContainerSupport
In addition, this change adds a JVM option that provides the ability to specify the number of CPUs that the JVM will use:
-XX:ActiveProcessorCount=count
This count overrides any other automatic CPU detection logic in the JVM.

30. Java Improvements for Docker Containers
JDK  Allow more flexibility in selecting Heap % of available RAM
Three new JVM options have been added to allow Docker container users to gain more fine grained control over the amount of system memory that will be used for the Java Heap:
-XX:InitialRAMPercentage -XX:MaxRAMPercentage -XX:MinRAMPercentage
These options replace the deprecated Fraction forms (-XX:InitialRAMFraction, -XX:MaxRAMFraction, and -XX:MinRAMFraction).

31. Optional.orElseThrow() Method
JDK : (opt) add no-arg orElseThrow() as preferred alternative to get()
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.

32. APIs for Creating Unmodifiable Collections
The List.copyOf, Set.copyOf, and Map.copyOf methods create new collection instances from existing instances.
toUnmodifiableList, toUnmodifiableSet, and toUnmodifiableMap have been added to the Collectors class in the Stream package.

33. Information For more information visit:

34. Questions?