Article Overview
➤ Overview of new features in JDK 9
➤ Significant changes in JDK 9
➤ New features in the JDK 9 installer
➤ New tools in JDK 9
➤ New security features in JDK 9
Overview of New Features in JDK 9
Java Platform, Standard Edition 9 is a major feature release. The following summarizes the characteristics and enhancements of Java SE 9 and JDK 9 as implemented by Oracle.
JDK Enhancement Proposals (JEPs) are proposals for significant changes to the design and implementation of the JDK.
See JEP 1: JDK Enhancement-Proposal and Roadmap Process.
Java Specification Requests (JSRs) describe the specifications and final standards for the Java platform.
See JSR Overview.
Significant Changes in JDK 9
These changes affect multiple technical areas.
Java Platform Module System
A new Java programming component called a module has been introduced, which is a specified, self-describing collection of code and data.
Module System:
☞ Introduced a new optional phase, link time, which occurs between compile time and run time, during which a set of modules can be combined and optimized into a custom runtime image; see the jlink tool in the Java Platform, Standard Edition Tools Reference.
☞ Added options to the tools javac, jlink, and java to specify where the module path is and which modules are defined.
☞ Introduced modular JAR files, which are JAR files that contain a module-info.class in the root directory.
☞ Launched the JMOD format, a packaging format similar to JAR, which can include native code and configuration files; see the jmod tool.
The JDK itself has been divided into a set of modules. This change:
☞ Allows you to combine JDK modules into various configurations, including:
• Configurations corresponding to JRE and JDK.
• Configurations that are roughly equivalent to the contents of the various compact profiles defined in Java SE 8.
• Custom configurations that include only a specified set of modules and their required modules.
☞ Reorganizes the JDK and JRE runtime images to accommodate modules and improve performance, security, and maintainability.
☞ Reorganizes the JDK and JRE runtime images to accommodate modules and improve performance, security, and maintainability.
☞ Defines a new URI scheme for naming modules, classes, and resources stored in the runtime image that does not expose the internal structure or format of the image.
☞ Removes the endorsed-standards override mechanism and extension mechanism.
☞ Removes rt.jar and tools.jar from the Java runtime image.
☞ Makes most internal APIs of the JDK inaccessible by default, while leaving some key, widely used internal APIs accessible until all or most features are supported by alternatives.
Run the command jdeps -jdkinternals to determine if your code uses internal JDK APIs.
For more details, see the following:
☞ Java Platform Module System (JSR 376)
☞ JEP 261: Module System
☞ JEP 200: Modular JDK
☞ JEP 220: Modular Runtime Image
☞ JEP 260: Encapsulation of Most Internal APIs
JEP 223:
New Version-String Scheme
Provides a simplified version-string format that helps clearly distinguish between major, minor, security, and patch update versions.
The new version string format is as follows:
$MAJOR.$MINOR.$SECURITY.$PATCH
☞ $MAJOR is the version number incremented for major releases, such as JDK 9, which includes significant new features specified by the Java SE platform specification. Major releases include new features and changes to existing features that are planned and announced in advance.
☞ $MINOR is the version number incremented for each minor update, such as bug fixes, revisions to standard APIs, or implementations of features outside the scope of related platform specifications.
☞ $SECURITY is the version number incremented for security update releases, which include critical fixes, including patches necessary to improve security.
☞ $PATCH is the version number for releases that include security and high-priority customer patches that have been tested together.
See the new Version-String format in the Java Platform, Standard Edition Installation Guide.
New Features in the JDK 9 Installer
JDK 9 includes enhancements to the installer for Microsoft Windows and macOS platforms.
Microsoft Windows
Installer Enhancements
☞ Enable or disable Web Deployment using the installer user interface
Provides an option to enable or disable Web Deployment on the installer’s “Welcome” page. To enable Web Deployment, select “Custom Install” on the “Welcome” page, click “Install,” and then check the “Enable Java content in browsers” checkbox.
macOS
Installer Enhancements
☞ Availability of CPU version
Provides notification about the availability of the next CPU after uninstalling the current CPU version.
☞ User Experience
Optimizes user experience when updating the JRE.
New Tools in JDK 9
JEP 222: jshell:
Java Shell
(Read-Eval-Print Loop)
Adds interactive interpreter environment (REPL) capabilities to the Java platform.
The jshell tool provides an interactive command-line interface for evaluating declarations, statements, and expressions in the Java programming language. It aids in prototyping and exploring coding options, with immediate results and feedback. Direct feedback combined with the ability to start expressing is useful for education—whether learning the Java language or just learning new APIs or language features.
See jshell in the Java Platform, Standard Edition Tools Reference, and the Java Shell User Guide in the Java Platform, Standard Edition.
The JShell API allows applications to leverage REPL capabilities. See the jdk.jshell package.
JEP 228:
Add More Diagnostic Commands
Defines additional diagnostic commands to enhance the ability to diagnose Hotspot and JDK issues.
See jcmd in the Java Platform, Standard Edition Tools Reference.
JEP 231:
Remove JRE Version Selection at Startup
Removes the ability to request a JRE version that is not the JRE that is started at startup.
Modern applications are typically deployed via Java Web Start (using JNLP files), native OS packaging systems, or active installers. These technologies have their own methods for managing the required JRE lookup or download and update as needed. This makes JRE version selection at startup obsolete.
JEP 238:
Multi-Version JAR Files
Extends the JAR file format to allow sharing of class files for multiple Java versions in a single archive.
Multi-Version JAR (MRJAR) contains additional versioned directories for classes and resources specific to a particular Java platform version. Use the jar tool with the –release option to specify versioned directories.
JEP 240:
Remove JVM TI hprof Agent
Removes the hprof agent from the JDK. The hprof agent was written as demonstration code for the JVM Tool Interface and was not intended to be a production tool.
Useful features of the hprof agent have been replaced by better alternatives.
Note:
When the hprof agent has been removed, hprof can still create heap dumps in the format used by jmap or other diagnostic tools. See the Java Platform, Standard Edition Troubleshooting Guide for diagnostic tools.
JEP 241:
Remove jhat Tool
Removes the jhat tool from the JDK.
The jhat tool was an experimental and unsupported tool added in JDK 6. It has been deprecated for years. Advanced heap visualizers and analyzers have been available for many years.
JEP 245:
Validate JVM Command-Line Flags Parameters
Validates the parameters of all numeric JVM command-line flags to avoid failures, displaying appropriate error messages if they are found to be invalid.
Range and optional constraint checks have been implemented for parameters that require user-specified numeric values.
See java and validate Java Virtual Machine flag parameters in the Java Platform, Standard Edition Tools Reference.
JEP 247:
Compile for Older Platform Versions
Enhances javac so that it can compile Java programs to run on selected earlier versions of the platform.
When using the –source or –target options, compiled programs may inadvertently use APIs not supported by the given target platform. The –release option prevents accidental use of APIs.
See javac in the Java Platform, Standard Edition Tools Reference.
JEP 282:
jlink: Java Linker
Combines and optimizes a set of modules and their dependencies into a custom runtime image, as defined in JEP 220.
The jlink tool defines a plugin mechanism for transformation and optimization during assembly, as well as for generating alternative image formats. It can create a custom runtime optimized for a single application. JEP 261 defines link time as an optional phase between compile time and run time. Link time requires a linking tool to combine and optimize a set of modules and their transitive dependencies to create a runtime image or executable.
See jlink in the Java Platform, Standard Edition Tools Reference.
New Security Features in JDK 9
JEP 219:
Datagram Transport Layer Security
(DTLS)
Enables the Java Secure Socket Extension (JSSE) API and the SunJSSE security provider to support DTLS version 1.0 and DTLS version 1.2 protocols.
See Datagram Transport Layer Security (DTLS) in the Java Platform, Standard Edition Security Developer Guide.
JEP 244:
TLS Application Layer Protocol Negotiation Extension
Enables clients and servers in a Transport Layer Security (TLS) connection to negotiate which application protocol to use. Using Application Layer Protocol Negotiation (ALPN), the client sends a list of supported application protocols as part of the TLS ClientHello message. The server selects a protocol and returns the selected protocol as part of the TLS ServerHello message. Application protocol negotiation can be completed during the TLS handshake without requiring additional network round trips.
See TLS Handshake and Application Layer Protocol Negotiation in the Java Platform, Standard Edition Security Developer Guide.
JEP 249:
OCSP Stapling for TLS
Enables servers in TLS connections to check the revocation status of X.509 certificates. The server performs this during the TLS handshake by contacting an Online Certificate Status Protocol (OCSP) responder regarding the certificate. It then attaches or “staples” the revocation information to the certificate returned to the client so that the client can take appropriate action.
Enables clients to request OCSP stapling from TLS servers. Clients check the stapling response from servers that support this feature.
See OCSP Stapling in the Java Platform, Standard Edition Security Developer Guide.
JEP 246:
Utilizing GHASH and RSA CPU Instructions
AES/GCM/NoPadding uses GHASH HotSpot intrinsic functions, with performance improvements of 34x to 150x. The acceleration of GHASH intrinsic functions can be seen from the PCLMULQDQ Intel x64 CPU’s xmul/xmulhi instructions and SPARC instructions.
Using RSA HotSpot intrinsic functions, performance improvements of up to 50% are achieved for BigInteger squareToLen and BigInteger mulAdd methods. RSA intrinsic functions are applicable to the java.math.BigInteger class on Intel x64 platforms.
jdk.security.provider.preferred introduces a new security property to configure providers that can significantly enhance the performance of specific algorithms.
See Configuring Preferred Providers for Specific Algorithms in the Java Platform, Standard Edition Security Developer Guide.
JEP 273: DRBG-based SecureRandom Implementation
Provides SecureRandom functionality for the Deterministic Random Bit Generator (DRBG) mechanism specified in NIST SP 800-90Ar1.
The DRBG mechanism uses modern algorithms as strong as SHA-512 and AES-256. Each of these mechanisms can be configured with different security strengths and functionalities to match user needs.
See Generating Random Numbers in the Java Platform, Standard Edition Security Developer Guide.
JEP 288:
Disabling SHA-1 Certificates
Improves the security configuration of the JDK by providing a more flexible mechanism to disable X.509 certificate chains based on SHA-1 signatures. Disables SHA-1 certificates that are included by default in the JDK from root-linked TLS server certificate chains; local or enterprise Certificate Authorities (CAs) are unaffected.
jdk.certpath.disabledAlgorithms security property strengthens several new constraints, allowing for greater control over which types of certificates can be disabled.
See JEP 288.
JEP 229:Default Creation
PKCS12 Keystore
Changes the default keystore type from JKS to PKCS12. PKCS#12 is a standard, extensible, and widely supported format for storing encryption keys. PKCS12 keystores enhance confidentiality by storing private keys, trusted public key certificates, and keys. This feature also provides opportunities for interoperability with other systems (such as Mozilla, Microsoft Internet Explorer, and OpenSSL that support PKCS12).
The SunJSSE provider provides a complete implementation of PKCS12 format for reading and writing PKCS12 files using java.security.KeyStore.
See Key Management in the Java Platform, Standard Edition Security Developer Guide.
The keytool utility for managing keys and certificates can create PKCS12 keystores.
See Creating Keystores in the Java Platform, Standard Edition Security Developer Guide, and keytool in the Java Platform, Standard Edition Tools Reference.
JEP 287:
SHA-3 Hash Algorithm
Supports the SHA-3 cryptographic hash functions specified in NIST FIPS 202.
The java.security.MessageDigest API supports the following additional standard algorithms: SHA3-224, SHA3-256, SHA3-384, and SHA3-512.
The following providers support SHA-3 algorithm enhancements:
• SUN Provider: SHA3-224, SHA3-256, SHA3-384, and SHA3-512
• OracleUcrypto Provider: SHA-3 digests supported in Solaris 12.0
Next Issue Preview☟
➤New Deployment Features in JDK 9
➤ New Java Language Features in JDK 9
➤ New Javadoc Features in JDK 9
➤ New JVM Features in JDK 9
➤ New JVM Tuning Features in JDK 9
Original English Text☟
Recommended Reading
Possibly the most popular open-source project in the country — HTML/CSS Edition
TIOBE October Programming Language Rankings: Is Swift Becoming Obsolete?
New Features in PostgreSQL 10 Official Release, Significant Performance Improvements
10 Scripting Languages Compiled to JavaScript
Click “Read the Original” for more exciting content