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

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

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

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

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("http://www.oracle.com/"); URLConnection conn = url.openConnection(); Reader reader = new BufferedReader( new InputStreamReader(conn.getInputStream())); Java 10: var list = new ArrayList<String>(); var url = new URL("http://www.oracle.com/"); var conn = url.openConnection(); var reader = new BufferedReader( new InputStreamReader(conn.getInputStream()));

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>

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)

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.

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

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

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

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.

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

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)

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.

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)

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)

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 ==> "$"

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.

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.

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.

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

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.

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.

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.

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

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 10.0.1, the July release is JDK 10.0.2, 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

Java Improvements for Docker Containers JDK-8146115 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.

Java Improvements for Docker Containers JDK-8146115 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.

Java Improvements for Docker Containers JDK-8186248 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).

Optional.orElseThrow() Method JDK-8140281 : (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.

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.

Information For more information visit: http://openjdk.java.net/projects/jdk10/

Questions?