Professional Documents
Culture Documents
Overview of What's New in JDK 9: Java Platform, Standard Edition
Overview of What's New in JDK 9: Java Platform, Standard Edition
1
Feature Description
Java Platform Module Introduces a new kind of Java programing component, the
System module, which is a named, self-describing collection of code and
data. This module system:
• Introduces a new optional phase, link time, which is in-
between compile time and run time, during which a set of
modules can be assembled and optimized into a custom
runtime image; see the jlink tool in Java Platform, Standard
Edition Tools Reference.
• Adds options to the tools javac, jlink, and java where you
can specify module paths, which locate definitions of
modules.
• Introduces the modular JAR file, which is a JAR file with a
module-info.class file in its root directory.
• Introduces the JMOD format, which is a packaging format
similar to JAR except it can include native code and
configuration files; see the jmod tool.
The JDK itself has been divided into a set of modules. This
change:
• Enables you to combine the JDK's modules into a variety of
configurations, including:
– Configurations corresponding to the JRE and the JDK.
– Configurations roughly equivalent in content to each of
the Compact Profiles defined in Java SE 8.
– Custom configurations that contain only a specified set of
modules and their required modules.
• Restructures 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 a runtime image without revealing the
internal structure or format of the image.
• Removes the endorsed-standards override mechanism and
the extension mechanism.
• Removes rt.jar and tools.jar from the Java runtime
image.
• 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 jdeps -jdkinternals to determine if your
code uses internal JDK APIs.
For more information, see the following:
• Java Platform Module System (JSR 376)
• JEP 261: Module System
• JEP 200: The Modular JDK
• JEP 220: Modular Run-Time Images
• JEP 260: Encapsulate Most Internal APIs
2
Feature Description
JEP 223: New Version- Provides a simplified version-string format that helps to clearly
String Scheme distinguish major, minor, security, and patch update releases.
The new version-string format is as follows:
$MAJOR.$MINOR.$SECURITY.$PATCH
3
What’s New for Tools in JDK 9
These are the tools enhancements in JDK 9.
Feature Description
JEP 222: jshell: The Java Adds Read-Eval-Print Loop (REPL) functionality to the Java
Shell (Read-Eval-Print platform.
Loop) The jshell tool provides an interactive command-line interface for
evaluating declarations, statements, and expressions of the Java
programming language. It facilitates prototyping and exploration of
coding options with immediate results and feedback. The
immediate feedback combined with the ability to start with
expressions is useful for education—whether learning the Java
language or just learning a new API or language feature.
See jshell in Java Platform, Standard Edition Tools Reference,
and Introduction to JShell in Java Platform, Standard Edition Java
Shell User’s Guide.
The JShell API enables applications to leverage REPL
functionality. See the jdk.jshell package.
JEP 228: Add More Defines additional diagnostic commands to improve the ability to
Diagnostic Commands diagnose issues with Hotspot and the JDK.
See jcmd in Java Platform, Standard Edition Tools Reference.
JEP 231: Remove Launch- Removes the ability to request a version of the JRE that is not the
Time JRE Version JRE being launched at launch time.
Selection Modern applications are typically deployed through Java Web
Start (with a JNLP file), 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 launch-time JRE version
selection obsolete.
JEP 238: Multi-Release Extends the JAR file format to enable multiple, Java release-
JAR Files specific versions of class files to coexist in a single archive.
A multirelease JAR (MRJAR) contains additional, versioned
directories for classes and resources specific to particular Java
platform releases. Specify versioned directories with the jar tool's
--release option.
4
Feature Description
JEP 240: Remove the Removes the hprof agent from the JDK. The hprof agent was
JVM TI hprof Agent written as demonstration code for the JVM Tool Interface and not
intended to be a production tool.
The useful features of the hprof agent have been superseded by
better alternatives.
Note:
While the hprof agent has been removed, it is still possible to
create heap dumps in the hprof format using jmap or other
diagnostic tools. See Diagnostic Tools in Java Platform, Standard
Edition Troubleshooting Guide.
JEP 241: Remove the jhat Removes the jhat tool from the JDK.
Tool The jhat tool was an experimental and unsupported tool added in
JDK 6. It is out of date; superior heap visualizers and analyzers
have been available for many years.
JEP 245: Validate JVM Validates arguments to all numerical JVM command-line flags to
Command-Line Flag avoid failures and instead displays an appropriate error message if
Arguments they are found to be invalid.
Range and optional constraint checks have been implemented for
arguments that require a user-specified numerical value.
See java and Validate Java Virtual Machine Flag Arguments in
Java Platform, Standard Edition Tools Reference.
JEP 247: Compile for Enhances javac so that it can compile Java programs to run on
Older Platform Versions selected earlier versions of the platform.
When using the -source or -target options, the compiled
program might accidentally use APIs that are not supported on the
given target platform. The --release option will prevent accidental
use of APIs.
See javac in Java Platform, Standard Edition Tools Reference.
JEP 282: jlink: The Java Assembles and optimizes a set of modules and their
Linker dependencies into a custom runtime image as defined in JEP 220.
The jlink tool defines a plug-in mechanism for transformation and
optimization during the assembly process, and for the generation
of alternative image formats. It can create 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.
See jlink in Java Platform, Standard Edition Tools Reference.
5
These are the security enhancements in JDK 9.
Feature Description
JEP 219: Datagram Enables Java Secure Socket Extension (JSSE) API and the
Transport Layer Security SunJSSE security provider to support DTLS Version 1.0 and
(DTLS) DTLS Version 1.2 protocols.
See Datagram Transport Layer Security (DTLS) in Java Platform,
Standard Edition Security Developer's Guide.
JEP 244: TLS Application- Enables the client and server in a Transport Layer Security (TLS)
Layer Protocol Negotiation connection to negotiate the application protocol to be used. With
Extension Application-Layer Protocol Negotiation (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 be accomplished within
the TLS handshake, without adding network round-trips.
See TLS Handshake and Application Layer Protocol Negotiation in
Java Platform, Standard Edition Security Developer's Guide.
JEP 249: OCSP Stapling Enables the server in a TLS connection to check for a revoked X.
for TLS 509 certificate revocation. The server does this during TLS
handshaking by contacting an Online Certificate Status Protocol
(OCSP) responder for the certificate in question. It then attaches
or "staples" the revocation information to the certificate that 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 Java Platform, Standard Edition Security
Developer's Guide.
JEP 246: Leverage CPU Improves performance ranging from 34x to 150x for AES/GCM/
Instructions for GHASH NoPadding using GHASH HotSpot intrinsics. GHASH intrinsics are
and RSA accelerated by the PCLMULQDQ instruction on Intel x64 CPU and the
xmul/xmulhi instructions on SPARC.
Improves performance up to 50% for BigInteger squareToLen
and BigInteger mulAdd methods using RSA HotSpot intrinsics.
RSA intrinsics apply to the java.math.BigInteger class on Intel
x64.
A new security property jdk.security.provider.preferred is
introduced to configure providers that offer significant performance
gains for specific algorithms.
See Configuring the Preferred Provider for Specific Algorithms in
Java Platform, Standard Edition Security Developer's Guide.
JEP 273: DRBG-Based Provides the functionality of Deterministic Random Bit Generator
SecureRandom (DRBG) mechanisms as specified in NIST SP 800-90Ar1 in the
Implementations SecureRandom API.
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 Java Platform, Standard
Edition Security Developer's Guide.
6
Feature Description
JEP 288: Disable SHA-1 Improves the security configuration of the JDK by providing a more
Certificates flexible mechanism to disable X.509 certificate chains with SHA-1-
based signatures.
Disables SHA-1 in TLS Server certificate chains anchored by roots
included by default in the JDK; local or enterprise certificate
authorities (CAs) are not affected.
The jdk.certpath.disabledAlgorithms security property is
enhanced with several new constraints that allow greater control
over the types of certificates that can be disabled.
See JEP 288.
JEP 229: Create PKCS12 Modifies the default keystore type from JKS to PKCS12. PKCS#12
Keystores by Default 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 java.security.KeyStore format for reading and writing
PKCS12 files.
See Key Management in Java Platform, Standard Edition Security
Developer's Guide.
The keytool key and certificate management utility can create
PKCS12 keystores.
See Creating a Keystore in Java Platform, Standard Edition
Security Developer's Guide and keytool in Java Platform,
Standard Edition Tools Reference.
JEP 287: SHA-3 Hash Supports SHA-3 cryptographic hash functions as specified in NIST
Algorithms FIPS 202.
The following additional standard algorithms are supported by the
java.security.MessageDigest API: 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 by Solaris
12.0
7
Feature Description
Deprecate the Java Plug- Deprecates the Java Plug-in and associated applet technologies in
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.
See Migrating Java Applets to Java Web Start and JNLP and Self-
Contained Application Packaging in Java Platform, Standard
Edition Deployment Guide.
Enhanced Java Control Improves the grouping and presentation of options within the Java
Panel Control Panel. Information is easier to locate, a search field is
available, and modal dialog boxes 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 Java Platform, Standard Edition
Deployment Guide.
JEP 275: Modular Java Integrates features from Project Jigsaw into the Java Packager,
Application Packaging including module awareness and custom runtime creation.
Leverages the jlink tool to create smaller packages.
Creates applications that use the JDK 9 runtime only. Cannot be
used to package applications with an earlier release of the JRE.
See Customization of the JRE and Packaging for Modular
Applications in Java Platform, Standard Edition Deployment
Guide.
JEP 289: Deprecate the Deprecates the Applet API, which is becoming less useful as web
Applet API 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.
See Migrating Java Applets to Java Web Start and JNLP and Self-
Contained Application Packaging in Java Platform, Standard
Edition Deployment Guide.
8
Feature Description
JEP 213: Milling Project Coin Identifies a few small changes:
• Allow @SafeVargs on private instance methods.
• Allow effectively final variables to be used as
resources in the try-with-resources statement.
• Allow the diamond with anonymous classes if the
argument type of the inferred type is denotable.
• Complete the removal, begun in Java SE 8, of the
underscore from the set of legal identifier names.
• Add support for private interface methods.
See Java Language Changes for Java SE 9 in Java
Platform, Standard Edition Java Language Updates.
Feature Description
JEP 221: Simplified Doclet Replaces the old Doclet API with a new simplified API that
API 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. Use
this search box to find program elements, tagged words, and
phrases within the documentation.
JEP 261: Module System Supports documentation comments in module declarations.
Includes new command-line options to configure the set of
modules to be documented and generates a new summary page
for any modules being documented.
9
Feature Description
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 Java Platform, Standard Edition Java
Virtual Machine Guide.
JEP 197: Segmented Divides the code cache into distinct segments, each of which
Code Cache contains compiled code of a particular type, to improve
performance and enable future extensions.
See java in Java Platform, Standard Edition Tools Reference.
JEP 276: Dynamic Linking Dynamically links high-level object operations at run time, such as
of Language-Defined read a property, write a property, and invoke a function, to the
Object Models appropriate target method handles. It links these operations to
target method handles based on the actual types of the values
passed. These object operations are expressed as
invokedynamic sites.
While java.lang.invoke provides a low-level API for
dynamic linking of invokedynamic call sites, it doesn't 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).
Feature Description
Improve G1 Usability, Enhances the Garbage-First (G1) garbage collector to
Determinism, and automatically determine several important memory-reclamation
Performance settings. Previously these settings had to be set manually to obtain
optimal results. In addition, fixes issues with the usability,
determinism, and performance of the G1 garbage collector.
JEP 158: Unified JVM Introduces a common logging system for all components of the
Logging JVM.
See the -Xloggc java option in Java Platform, Standard Edition
Tools Reference.
10
Feature Description
JEP 214: Remove GC Removes garbage collector (GC) combinations that were
Combinations Deprecated deprecated in JDK 8.
in JDK 8 This means that the following GC combinations no longer exist:
• DefNew + CMS
• ParNew + SerialOld
• Incremental CMS
The "foreground" mode for Concurrent Mark Sweep (CMS) has
also been removed. The following command-line flags have been
removed:
• -Xincgc
• -XX:+CMSIncrementalMode
• -XX:+UseCMSCompactAtFullCollection
• -XX:+CMSFullGCsBeforeCompaction
• -XX:+UseCMSCollectionPassing
The command line flag -XX:+UseParNewGC no longer has an effect.
ParNew can only be used with CMS and CMS requires ParNew.
Thus, the -XX:+UseParNewGC flag has been deprecated and will
likely be removed in a future release.
JEP 248: Make G1 the Makes Garbage-First (G1) the default garbage collector (GC) on
Default Garbage Collector 32- and 64-bit server configurations. Using a low-pause collector
such as G1 provides a better overall experience, for most users,
than a throughput-oriented collector such as the Parallel GC,
which was previously the default.
See Garbage-First Garbage Collector in Java Platform, Standard
Edition HotSpot Virtual Machine Garbage Collection Tuning Guide
JEP 271: Unified GC Reimplements Garbage Collection (GC) logging using the unified
Logging 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
Java Platform, Standard Edition Tools Reference.
JEP 291: Deprecate the Deprecates the Concurrent Mark Sweep (CMS) garbage collector.
Concurrent Mark Sweep A warning message is issued when it is requested on the
(CMS) Garbage Collector command line, using the -XX:+UseConcMarkSweepGC option. The
Garbage-First (G1) garbage collector is intended to be a
replacement for most uses of CMS.
11
Feature Description
JEP 102: Improves the API for controlling and managing operating system processes.
Process API The ProcessHandle class provides the process's native process ID,
Updates arguments, command, start time, accumulated CPU time, user, parent
process, and descendants. The class can also monitor processes' liveness
and destroy processes. With the ProcessHandle.onExit method, the
asynchronous mechanisms of the CompletableFuture class can
perform an action when the process exits.
See Process API in Java Platform, Standard Edition Java Core Libraries
Developer's Guide, java.lang.Process, and
java.lang.ProcessHandle.
JEP 193: Defines a standard means to invoke the equivalents of
Variable Handles java.util.concurrent.atomic and sun.misc.Unsafe
operations upon object fields and array elements.
Defines a standard set of fence operations, which consist of VarHandle
static methods that enable fine-grained control of memory ordering. This is
an alternative to sun.misc.Unsafe, which provides a nonstandard set
of fence operations.
Defines a standard reachability fence operation to ensure that a referenced
object remains strongly reachable.
JEP 254: Adopts a more space-efficient internal representation for strings. Previously,
Compact Strings the String class stored characters in a char array, using two bytes (16
bits) for each character. The new internal representation of the String
class is a byte array plus an encoding-flag field.
This is purely an implementation change, with no changes to existing public
interfaces.
See the CompactStrings option of the java command in Java Platform,
Standard Edition Tools Reference.
JEP 264: Defines a minimal logging API that platform classes can use to log
Platform Logging messages, together with a service interface for consumers of those
API and Service messages. A library or application can provide an implementation of this
service to route platform log messages to the logging framework of its
choice. If no implementation is provided, then a default implementation
based on the java.util.logging API is used.
JEP 266: More Adds further concurrency updates to those introduced in JDK 8 in JEP 155:
Concurrency Concurrency Updates, including an interoperable publish-subscribe
Updates framework and enhancements to the CompletableFuture API.
JEP 268: XML Adds a standard XML Catalog API that supports the Organization for the
Catalogs Advancement of Structured Information Standards (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 to take advantage of the new features.
See XML Catalog API in Java Platform, Standard Edition Java Core
Libraries Developer's Guide.
12
Feature Description
JEP 269: Makes it easier to create instances of collections and maps with small
Convenience numbers of elements. New static factory methods on the List, Set, and Map
Factory Methods interfaces make it simpler to create immutable instances of those
for Collections collections.
For example:
Set<String> alphabet = Set.of("a", "b", "c");
See Creating Immutable Lists, Sets, and Maps in Java Platform, Standard
Edition Java Core Libraries Developer's Guide. For API documentation, see
Immutable Set Static Factory Methods, Immutable Map Static Factory
Methods, and Immutable List Static Factory Methods.
JEP 274: Enhances the MethodHandle, MethodHandles, and
Enhanced MethodHandles.Lookup classes of the java.lang.invoke
Method Handles package to ease common use cases and enable better compiler
optimizations.
Additions include:
• In the MethodHandles class in the java.lang.invoke
package, provide new MethodHandle combinators for loops and
try/finally blocks.
• Enhance the MethodHandle and MethodHandles classes with
new MethodHandle combinators for argument handling.
• Implement new lookups for interface methods and, optionally, super
constructors in the MethodHandles.Lookup class.
JEP 277: Revamps the @Deprecated annotation to provide better information
Enhanced about the status and intended disposition of an API in the specification. Two
Deprecation new elements have been added:
• @Deprecated(forRemoval=true) indicates that the API will be
removed in a future release of the Java SE platform.
• @Deprecated(since="version") contains the Java SE
version string that indicates when the API element was deprecated, for
those deprecated in Java SE 9 and beyond.
For example: @Deprecated(since="9", forRemoval=true)
@Deprecated annotations in the core platform have been updated.
You can use a new tool, jdeprscan, to scan a class library (JAR file) for
uses of deprecated JDK API elements.
See Enhanced Deprecation in Java Platform, Standard Edition Java Core
Libraries Developer's Guide.
See jdperscan in Java Platform, Standard Edition Tools Reference.
JEP 285: Spin- Defines an API that enables Java code to hint that a spin loop is executing.
Wait Hints A spin loop repeatedly checks to see if a condition is true, such as when a
lock can be acquired, after which some computation can be safely
performed followed by the release of the lock. This API is purely a hint, and
carries no semantic behavior requirements. See the method
Thread.onSpinWait.
13
Feature Description
JEP 290: Filter Allows incoming streams of object-serialization data to be filtered to improve
Incoming both security and robustness. Object-serialization clients can validate their
Serialization input more easily, and exported Remote Method Invocation (RMI) objects
Data 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- Provides a stack-walking API that allows easy filtering and lazy access to
Walking API 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 interested only in the top 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.
JEP 255: Merge Updates the JDK to support the 2.11.0 version of the Xerces parser. There
Selected Xerces is no change to the public JAXP API.
2.11.0 Updates The changes are in the following categories of Xerces 2.11.0: Datatypes,
into JAXP DOM L3 Serializer, XPointer, Catalog Resolver, and XML Schema
Validation (including bug fixes, but not the XML Schema 1.1 development
code).
Feature Description
JEP 236: Parser API for Enables applications, in particular IDEs and server-side
Nashorn 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 Implements many new features introduced in the 6th edition of
Selected ECMAScript 6 ECMA-262, also known as ECMAScript 6, or ES6 for short.
Features in Nashorn Implemented features include the following:
• Template strings
• let, const, and block scope
• Iterators and for..of loops
• Map, Set, WeakMap, and WeakSet
• Symbols
• Binary and octal literals
14
What’s New for Client Technologies in JDK 9
These are the client technologies enhancements in JDK 9.
Feature Description
JEP 251: Multi- Enables a set of images with different resolutions to be
Resolution Images encapsulated into a single multiresolution image. This could be
useful for 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
multiresolution image, which enables applications to easily
manipulate and display images with resolution variants.
JEP 253: Prepare Provides public APIs for JavaFX UI controls and CSS functionality
JavaFX UI Controls and that were previously available only through internal packages but
CSS APIs for are now inaccessible due to modularization.
Modularization The new package javafx.scene.control.skin consists of a set of
classes that provides a default implementation for the skin (or the
look) of each UI control.
The new class CssParser is a CSS parser that returns a
Stylesheet object, which gives you more control over the CSS
styling of your application. It’s part of the CSS API (the javafx.css
package). The CSS API includes new support classes, including a
set of standard converters used by the parser; see the
javafx.css.converter package.
JEP 256: BeanInfo Replaces the @beaninfo Javadoc tag with the annotation types
Annotations JavaBean, BeanProperty, and SwingContainer.
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 Automatically scales and sizes AWT and Swing components for
on Windows and Linux 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.
15
Feature Description
JEP 272: Platform- Adds additional methods to the class java.awt.Desktop that
Specific Desktop enable you to interact with the desktop, including the following:
Features • Show custom About and Preferences windows.
• Handle requests to open or print a list of files.
• Handle requests to open a URL.
• Open the native help viewer application.
• Set the default menu bar.
• Enable or disable the application to be suddenly terminated.
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.
JEP 283: Enable GTK 3 Enables Java graphical applications, whether based on JavaFX,
on Linux Swing, or Abstract Window Toolkit (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
jdk.gtk.version. This system property may have a value of 2, 2.2,
or 3. You must set this property before your application loads GTK
+, and it must not conflict with a GTK+ version that may have been
loaded earlier by another toolkit.
Feature Description
JEP 267: Unicode 8.0 Supports Unicode 8.0. JDK 8 supported Unicode 6.2.
The Unicode 6.3, 7.0 and 8.0 standards combined introduced
10,555 characters, 29 scripts, and 42 blocks, all of which are
supported in JDK 9.
JEP 252: CLDR Locale Uses the Common Locale Data Repository's (CLDR) XML-based
Data Enabled by Default 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 java.locale.providers to a value with COMPAT ahead of
CLDR.
See CLDR Locale Data Enabled by Default in Java Platform,
Standard Edition Internationalization Guide.
16
Feature Description
JEP 226: UTF-8 Loads properties files in UTF-8 encoding. In previous releases,
Properties Files 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 Java Platform, Standard Edition
Internationalization Guide.
Documentation Accessibility
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.
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.
17