Beta Draft: 2017-02-13
What’s New in Oracle JDK 9
Java Platform, Standard Edition 9 is a major feature release. The following summarizes features and enhancements in Java SE 9 and in JDK 9, Oracle's implementation of Java SE 9.
A JDK Enhancement Proposal (JEP) is a proposal to design and implement a nontrivial change to the JDK. See JEP 1: JDK Enhancement-Proposal & Roadmap Process. A Java Specification Request (JSR) describes proposed and final specifications for the Java platform. See JSR Overview.
The most significant JDK 9 enhancement is the Java Platform Module System, which divides the JDK into a set of modules.
|JEP 261: Module System||Implements the Java Platform Module System, as specified by JSR 376. Changes include:
|JEP 200: The Modular JDK||
|JEP 220: Modular Run-Time Images||
Restructures the JDK and JRE runtime images to accommodate modules and to improve performance, security, and maintainability. Defines a new URI scheme for naming modules, classes, and resources stored in a runtime image without revealing the internal structure or format of the image. Removes the endorsed-standards override mechanism and the extension mechanism. Removes
|JEP 260: Encapsulate Most Internal APIs||
Makes most of the JDK's internal APIs inaccessible by default but leaves a few critical, widely used internal APIs accessible until supported replacements exist for all or most of their functionality.
Run the command
Other key changes in this release include a new version-string scheme.
|JEP 223: New Version-String Scheme||
Provides simplified version-string format that helps to clearly distinguish major, minor, security, and patch update releases.
The format of the new version-string is as follows:
See New Version String Format in the Java Platform, Standard Edition Installation Guide.
These are the tools enhancements in JDK 9.
|JEP 158: Unified JVM Logging||
Introduces a common logging system for all components of the JVM.
|JEP 214: Remove GC Combinations Deprecated in JDK 8||
Removes GC combinations that were deprecated in JDK 8.
This means that the following GC combinations no longer exist:
The "foreground" mode for CMS has also been removed. The following command line flags have been removed:
The command line flag
|JEP 222: jshell: The Java Shell (Read-Eval-Print Loop)||
Adds Read-Eval-Print Loop (REPL) functionality to the Java platform.
The JShell API enables applications to leverage REPL functionality.
|JEP 224: HTML5 Javadoc||
|JEP 228: Add More Diagnostic Commands||
Defines additional diagnostic commands to improve the ability to diagnose issues with Hotspot and the JDK.
|JEP 231: Remove Launch-Time JRE Version Selection||
Removes the ability to request a version of the JRE that is not the JRE being launched at launch time.
Modern applications are typically deployed through Java Web Start (JNLP), native OS packaging systems, or active installers. These technologies have their own methods to manage the JREs needed by finding or downloading and updating the required JRE as needed. This makes the launcher's Launch-Time JRE Version Selection obsolete.
|JEP 240: Remove the JVM TI hprof Agent||
The useful features of the
|JEP 241: Remove the jhat Tool||
|JEP 245: Validate JVM Command-Line Flag Arguments||
Validates arguments to all numerical JVM command-line flags to avoid crashes and instead displays an appropriate error message if they are found to be invalid.
Range and optional constraint checks have been implemented for arguments which require a user-specified numerical value.
|JEP 247: Compile for Older Platform Versions||
When using the
See javac in the Java Platform, Standard Edition Tools Reference for Oracle JDK .
|JEP 282: jlink: The Java Linker||
Adds a tool that assembles and optimizes a set of modules and their dependencies into a custom runtime image as defined in JEP 220. Defines a plugin mechanism for transformation and optimization during the assembly process, and for the generation of alternative image formats. Creates a custom runtime optimized for a single program. JEP 261 defines link time as an optional phase between the phases of compile time and run time. Link time requires a linking tool that assembles and optimizes a set of modules and their transitive dependencies to create a runtime image or executable.
These are the security enhancements in JDK 9.
|JEP 219: Datagram Transport Layer Security (DTLS)||
See Datagram Transport Layer Security (DTLS) in the Java Platform, Standard Edition Security Developer's Guide.
Enables the client and server in a TLS connection to negotiate the application protocol to be used. With ALPN, the client sends the list of supported application protocols as part of the TLS ClientHello message. The server chooses a protocol and returns the selected protocol as part of the TLS ServerHello message. The application protocol negotiation can thus be accomplished within the TLS handshake, without adding network round-trips.
See TLS Handshake and Application Layer Protocol Negotiation in the Java Platform, Standard Edition Security Developer's Guide.
|JEP 249: OCSP Stapling for TLS||
Enables the server in a TLS connection to check for X.509 certificate revocation. The server does this during TLS handshaking by contacting an OCSP responder for the certificate in question. It then attaches or "staples" the revocation information to the certificate it returns to the client so that the client can take appropriate action.
Enables the client to request OCSP stapling from a TLS server. The client checks stapled responses from servers that support the feature.
See OCSP Stapling in the Java Platform, Standard Edition Security Developer's Guide.
|JEP 246: Leverage CPU Instructions for GHASH and RSA||
Improves performance ranging from 34x to 150x for
Improves performance up to 50% for
A new security property
See Configuring the Preferred Provider for Specific Algorithms in the Java Platform, Standard Edition Security Developer's Guide.
|JEP 273: DRBG-Based SecureRandom Implementations||
The DRBG mechanisms use modern algorithms as strong as SHA-512 and AES-256. Each of these mechanisms can be configured with different security strengths and features to match user requirements.
See Generating Random Numbers in the Java Platform, Standard Edition Security Developer's Guide.
|JEP 229: Create PKCS12 Keystores by Default||
Modifies the default keystore type from JKS to PKCS12. PKCS#12 is an extensible, standard, and widely-supported format for storing cryptographic keys. PKCS12 keystores improve confidentiality by storing private keys, trusted public key certificates, and secret keys. This feature also opens opportunities for interoperability with other systems such as Mozilla, Microsoft's Internet Explorer, and OpenSSL that support PKCS12.
The SunJSSE provider supplies a complete implementation of the PKCS12
See Key Management in the Java Platform, Standard Edition Security Developer's Guide.
|JEP 287: SHA-3 Hash Algorithms||
Supports SHA-3 cryptographic hash functions as specified in NIST FIPS 202.
The following additional standard algorithms are supported by the
The following providers support SHA-3 algorithm enhancements:
These are the deployment enhancements in JDK 9.
|Deprecate the Java Plug-in||
Deprecates the Java Plug-in and associated applet technologies in Oracle's JDK 9 builds. While still available in JDK 9, these technologies will be considered for removal from the Oracle JDK and JRE in a future release.
Applets and JavaFX applications embedded in a web page require the Java Plug-in to run. Consider rewriting these types of applications as Java Web Start or self-contained applications.
|Enhanced Java Control Panel||
Improves the grouping and presentation of options within the Java Control Panel. Information is easier to locate, a search field is available, and modal dialogs are no longer used. Note that the location of some options has changed from previous versions of the Java Control Panel.
See Java Control Panel in the Java Platform, Standard Edition Deployment Guide.
|JEP 275: Modular Java Application Packaging||
Integrates features from Project Jigsaw into the Java Packager, including module awareness and custom runtime creation.
Creates applications that use the JDK 9 runtime only. Cannot be used to package applications with an earlier release of the JRE.
|JEP 289: Deprecate the Applet API||
Deprecates the Applet API, which is becoming less useful as web browser vendors remove support for Java browser plug-ins. While still available in JDK 9, the Applet class will be considered for removal in a future release. Consider rewriting applets as Java Web Start or self-contained applications.
A few very small language changes are included in Java SE 9.
|JEP 213: Milling Project Coin||
Identifies a few small changes:
See Java Language Changes for Java SE 9 in Java Platform, Standard Edition Java Language Updates.
Javadoc enhancements include the following: a simplified Doclet API, Javadoc search, support for generating HTML5 output, and support for documentation comments in module systems.
|JEP 221: Simplified Doclet API||
Replaces the old Doclet API with a new simplified API that leverages other standard, existing APIs. The standard doclet has been rewritten to use the new Doclet API.
Note:The existing API and old standard doclet are available, but have not been updated to support new language features, such as modules.
|JEP 224: HTML5 Javadoc||
Supports generating HTML5 output. To get fully compliant HTML5 output, ensure that any HTML content provided in documentation comments are compliant with HTML5.
|JEP 225: Javadoc Search||
Provides a search box to the generated API documentation. You can use this search box to search for program elements, tagged words, and phrases within the documentation.
|JEP 261: Module System||
Supports documentation comments in module declarations. It has new command-line options to configure the set of modules to be documented, and generates a new summary page for any modules being documented.
These are the VM enhancements in JDK 9.
|JEP 165: Compiler Control||
Provides a way to control JVM compilation through compiler directive options. The level of control is runtime-manageable and method specific. Compiler Control supersedes and is backward compatible with CompileCommand.
See Compiler Control in the Java Platform, Standard Edition Java Virtual Machine Guide.
|JEP 197: Segmented Code Cache||
Divides the code cache into distinct segments, each of which contains compiled code of a particular type, to improve performance and enable future extensions.
See java in the Java Platform, Standard Edition Tools Reference for Oracle JDK.
|JEP 276: Dynamic Linking of Language-Defined Object Models||
Dynamically links high-level object operations, such as read a property, write a property, and invoke a function, which are expressed as invokedynamic sites, to the appropriate target method handles at run time based on the actual types of the values passed. While java.lang.invoke provides a low-level API for dynamic linking of invokedynamic call sites, it does not provide a way to express higher level operations on objects nor methods that implement them.
With the package jdk.dynalink, you can implement programming languages whose expressions contain dynamic types (types that cannot be determined statically) and whose operations on these dynamic types are expressed as invokedynamic call sites (because the language's object model or type system doesn't closely match that of the JVM).
These are the JVM tuning enhancements in JDK 9.
|JEP 271: Unified GC Logging||
Re-implements Garbage Collection (GC) logging using the unified JVM logging framework introduced in JEP 158. GC logging is re-implemented in a manner consistent with the current GC logging format; however, some differences exist between the new and old formats.
See Enable Logging with the JVM Unified Logging Framework in the Java Platform, Standard Edition Tools Reference for Oracle JDK.
|JEP 248: Make G1 the Default Garbage Collector||
Makes G1 the default garbage collector on 32- and 64-bit server configurations. Using a low-pause collector such as G1 should provide a better overall experience, for most users, than a throughput-oriented collector such as the Parallel GC, which was previously the default.
These are the core libraries enhancements in JDK 9.
|JEP 102: Process API Updates||
Improves the API for controlling and managing operating system processes.
|JEP 193: Variable Handles||
Defines a standard means to invoke the equivalents of java.util.concurrent.atomic and
Defines a standard set of fence operations to enable fine-grained control of memory ordering. This is an alternative to
Defines a standard reachability fence operation to ensure a referenced object remains strongly reachable.
|JEP 254: Compact Strings||
Adopts a more space-efficient internal representation for strings. Previously, the String class stored characters in a
This is purely an implementation change, with no changes to existing public interfaces.
|JEP 264: Platform Logging API and Service||
Defines a minimal logging API which platform classes can use to log messages, together with a service interface for consumers of those messages. A library or application can provide an implementation of this service in order to route platform log messages to the logging framework of its choice. If no implementation is provided, a default implementation based on the java.util.logging API is used.
|JEP 266: More Concurrency Updates||
Provides an interoperable publish-subscribe framework, enhancements to the CompletableFuture API, and various other improvements.
|JEP 268: XML Catalogs||
Adds a standard XML Catalog API that supports the OASIS XML Catalogs version 1.1 standard. The API defines catalog and catalog-resolver abstractions that can be used as an intrinsic or external resolver with the JAXP processors that accept resolvers.
Existing libraries or applications that use the internal catalog API will need to migrate to the new API in order to take advantage of the new features.
|JEP 269: Convenience Factory Methods for Collections||
Makes it easier to create instances of collections and maps with small numbers of elements. New static factory methods on the
Set<String> alphabet = Set.of("a", "b", "c");
|JEP 274: Enhanced Method Handles||
|JEP 277: Enhanced Deprecation||
You can use a new tool,
|JEP 285: Spin-Wait Hints||
Defines an API which enables Java code to hint that a spin loop is executing. This API is purely a hint, and carries no semantic behavior requirements. See the method Thread.onSpinWait.
|JEP 290: Filter Incoming Serialization Data||
Allows incoming streams of object-serialization data to be filtered in order to improve both security and robustness. Object-serialization clients can validate their inputs more easily, and exported RMI objects can validate invocation arguments more easily as well.
Serialization clients implement a filter interface that is set on an ObjectInputStream. For RMI, the object is exported through a RemoteServerRef that sets the filter on the MarshalInputStream to validate the invocation arguments as they are unmarshalled.
|JEP 259: Stack-Walking API||
Provides a stack-walking API that allows easy filtering and lazy access to the information in stack traces.
The API supports both short walks that stop at a frame that matches given criteria, and long walks that traverse the entire stack. Stopping at a frame that matches a given criteria avoids the cost of examining all the frames if the caller is only interested in the top few frames on the stack. The API enables access to Class objects when the stack walker is configured to do so. See the class java.lang.Stackwalker.
These are the Nashorn enhancements in JDK 9.
|JEP 236: Parser API for Nashorn||
Enables applications, in particular IDEs and server-side frameworks, to parse and analyze ECMAScript code.
Parse ECMAScript code from a string, URL, or file with methods from the Parser class. These methods return an instance of CompilationUnitTree, which represents ECMAScript code as an abstract syntax tree.
The package jdk.nashorn.api.tree contains the Nashorn parser API.
|JEP 292: Implement Selected ECMAScript 6 Features in Nashorn||Implements many new features introduced in the 6th edition of ECMA-262, also known as ECMAScript 6, or ES6 for short. Implemented features include the following:
These are the client technologies enhancements in JDK 9.
|JEP 251: Multi-Resolution Images||
Enables applications to adapt to display devices whose resolutions may vary from approximately 96dpi to 300dpi during run time.
The interface java.awt.image.MultiResolutionImage encapsulates a set of images with different resolutions into a single multi-resolution image, which enables applications to easily manipulate and display images with resolution variants.
|JEP 256: BeanInfo Annotations||
These annotation types set the corresponding feature attributes during BeanInfo generation at runtime. Thus, you can more easily specify these attributes directly in Bean classes instead of creating a separate BeanInfo class for every Bean class. It also enables the removal of automatically-generated classes, which makes it easier to modularize the client library.
|JEP 262: TIFF Image I/O||
Adds Tag Image File Format (TIFF) reading and writing as standard to the package javax.imageio. The new package javax.imageio.plugins.tiff provides classes that simplify the optional manipulation of TIFF metadata.
|JEP 263: HiDPI Graphics on Windows and Linux||
Automatically scales and sizes AWT and Swing components for High Dots Per Inch (HiDPI) displays on Windows and Linux.
The JDK already supports HiDPI "retina displays" on OS X.
Prior to this release, on Windows and Linux, Java applications were sized and rendered based on pixels, even on HiDPI displays that can have pixel densities two to three times as high as traditional displays. This led to GUI components and windows that were too small to read or use.
|JEP 272: Platform-Specific Desktop Features||
Adds additional methods to the class java.awt.Desktop that enable you to interact with the desktop, including the following:
These new methods replace the functionality of the internal APIs contained in the OS X package com.apple.eawt which are not accessible by default in JDK 9. Note that the package com.apple.eio is no longer accessible and no public replacement exists in JDK 9.
|JEP 283: Enable GTK 3 on Linux||
Enables Java graphical applications, whether based on JavaFX, Swing, or AWT, to use either the GTK+ version 2 or version 3 on Linux or Solaris.
By default, the JDK on Linux or Solaris uses GTK+ 2 if available; if not, it uses GTK+ 3.
To use a specific version of GTK+, set the system property
These are the internationalization enhancements in JDK 9.
|JEP 267: Unicode 8.0||
Supports Unicode 8.0. JDK 8 supported Unicode 6.2.
|JEP 252: CLDR Locale Data Enabled by Default||
Uses the CLDR's XML-based locale data, first added in JDK 8, as the default locale data in JDK 9. In previous releases, the default was JRE.
To enable behavior compatible with JDK 8, set the system property
See CLDR Locale Data Enabled by Default in the Java Platform, Standard Edition Internationalization Guide.
|JEP 226: UTF-8 Properties Files||
Loads properties files in UTF-8 encoding. In previous releases, ISO-8859-1 encoding was used when loading property resource bundles. UTF-8 is a much more convenient way to represent non-Latin characters.
Most existing properties files should not be affected.
See UTF-8 Properties Files in the Java Platform, Standard Edition Internationalization Guide.
For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.
Access to Oracle Support
Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.
Java Platform, Standard Edition What’s New in Oracle JDK 9, Release 9
Copyright © 2017, Oracle and/or its affiliates. All rights reserved.
This document summarizes features and enhancements in Java SE 9 and in JDK 9, Oracle's implementation of Java SE 9.
This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.
This documentation is in preproduction status and is intended for demonstration and preliminary use only. It may not be specific to the hardware on which you are using the software. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to this documentation and will not be responsible for any loss, costs, or damages incurred due to the use of this documentation.