Log Message:
openjdk-bin: Update to 15

Changelog:
JDK 15 Release Notes

These notes describe important changes, enhancements, removed APIs and
features, deprecated APIs and features, and other information about JDK 15 and
Java SE 15. In some cases, the descriptions provide links to additional
detailed information about an issue or a change. This page does not duplicate
the descriptions provided by the Java SE 15 ( JSR 390) Platform Specification,
which provides informative background for all specification changes and might
also include the identification of removed or deprecated APIs and features not
described here. The Java SE 15 ( JSR 390) specification provides links to:

  * Annex 1: The complete Java SE 15 API Specification.

  * Annex 2: An annotated API specification showing the exact differences
    relative to Java SE 15. Informative background for these changes may be
    found in the list of approved Change Specification Requests for this
    release.

  * Annex 3: Java SE 15 Editions of The Java Language Specification and The
    Java Virtual Machine Specification. . The Java SE 15 Editions contain all
    corrections and clarifications made since the Java SE 14 Editions, as well
    as additions for new features.

You should be aware of the content in that document as well as the items
described in this page.

The descriptions on this Release Note page also identify potential
compatibility issues that you might encounter when migrating to JDK 15. The
Kinds of Compatibility page on the OpenJDK wiki identifies three types of
potential compatibility issues for Java programs used in these descriptions:

  * Source: Source compatibility preserves the ability to compile existing
    source code without error.

  * Binary: Binary compatibility is defined in The Java Language Specification
    as preserving the ability to link existing class files without error.

  * Behavioral: Behavioral compatibility includes the semantics of the code
    that is executed at runtime.

See CSRs Approved for JDK 15 for the list of CSRs closed in JDK 15 and the
Compatibility & Specification Review (CSR) page on the OpenJDK wiki for general
information about compatibility.

Contents

  * New Features
  * Removed Features and Options
  * Deprecated Features and Options
  * Known Issues
  * Other Notes

New Features

This section describes some of the enhancements in Java SE 15 and JDK 15. In
some cases, the descriptions provide links to additional detailed information
about an issue or a change. The APIs described here are those that are provided
with the Oracle JDK. It includes a complete implementation of the Java SE 15
Platform and additional Java APIs to support developing, debugging, and
monitoring Java applications. Another source of information about important
enhancements and new features in Java SE 15 and JDK 15 is the Java SE 15 ( JSR
390) Platform Specification, which documents the changes to the specification
made between Java SE 14 and Java SE 15. This document includes descriptions of
those new features and enhancements that are also changes to the specification.
The descriptions also identify potential compatibility issues that you might
encounter when migrating to JDK 15.

Support for Unicode 13.0 (JDK-8239383)

core-libs/java.lang

This release upgrades Unicode support to 13.0, which includes the following:

  * The java.lang.Character class supports Unicode Character Database of 13.0
    level, which 13.0 adds 5,930 characters, for a total of 143,859 characters.
    These additions include 4 new scripts, for a total of 154 scripts, as well
    as 55 new emoji characters.
  * The java.text.Bidi and java.text.Normalizer classes support 13.0 level of
    Unicode Standard Annexes, #9 and #15, respectively.
  * The java.util.regex package supports Extended Grapheme Clusters based on
    13.0 level of Unicode Standard Annex #29 For more detail about Unicode
    13.0, refer to the Unicode Consortium's release note.

Added isEmpty Default Method to CharSequence (JDK-8215401)

core-libs/java.lang

java.lang.CharSequence has been updated in this release to define a default
isEmpty method that tests if a character sequence is empty. Testing for, and
filtering out, empty Strings and other CharSequences is a common occurrence in
code and CharSequence::isEmpty can be used as a method reference. Classes that
implement java.lang.CharSequence and another interface that defines isEmpty
method should be aware of this addition as they may need to be modified to
override the isEmpty method.

JEP 371: Hidden Classes (JDK-8238358)

core-libs/java.lang.invoke

JEP 371 introduces hidden classes in Java 15. Hidden classes have the following
implications to existing code:

 1. Class::getName traditionally returns a binary name, but for a hidden class
    it returns a string that contains an ASCII forward slash (/) and is
    therefore not a binary name. Programs that assume the returned string is a
    binary name might need to be updated to handle hidden classes. That said,
    the longstanding practice of Unsafe::defineAnonymousClass was to define
    classes whose names were not binary names, so some programs may already
    handle such names successfully.

 2. Class::descriptorString and MethodType::descriptorString returns a string
    that contains a ASCII dot (.) for a hidden class and therefore is not a
    type descriptor conforming to JVMS 4.3. Programs that assume the returned
    string is a type descriptor that conforms to JVMS 4.3 might need to be
    updated to handle hidden classes.

 3. Class::getNestMembers is changed to not throw an exception when it fails to
    validate a nest membership of any member listed in NestMembers attribute.
    Instead, Class::getNestMembers returns the nest host and the members listed
    in the host's NestMembers attribute that are successfully resolved and
    determined to have the same nest host as this class. (This means it may
    return fewer members that listed in NestMembers attribute.) Existing code
    that expects LinkageError when there is a bad nest membership might be
    impacted.

 4. The nestmate test in the JVM is changed to throw only IllegalAccessError
    when the nest membership is invalid. Some historical understanding is
    necessary:

  * In Java 8, every access control failure was signaled with
    IllegalAccessError (IAE). Moreover, if a given access check failed with IAE
    once, then the same check would fail with IAE every time.
  * In Java 11, the introduction of nest mates (JEP 181) meant that an access
    control failure could be signaled either with IllegalAccessError or, if
    nest membership was invalid, LinkageError. Still, if a given access check
    failed with a specific exception, then the same check would always fail
    with the same exception.
  * In Java 15, the introduction of Lookup::defineHiddenClass implies that the
    nest host of the lookup class must be determined eagerly, when the hidden
    class is defined as a nestmate of the lookup class. Both
    Lookup::defineHiddenClass and Class::getNestHost both determine the nest
    host of a class in a more resilient manner than the JVM did in Java 11;
    namely, the API simply treats a class as self-hosted if its purported nest
    membership is invalid. For consistency with the API, the JVM no longer
    throws LinkageError when a class's nest membership is invalid, and instead
    treats the class as self-hosted. This means that the JVM only throws IAE
    from access control (because a self-hosted class will not permit any other
    class to access its private members). This is the behavior expected by the
    vast majority of user code.

 5. JVM TI GetClassSignature returns a string that contains a ASCII dot (.) for
    a hidden class. JVM TI agents might need updating for hidden classes if
    they assume the returned string from GetClassSignature is a type descriptor
    conforming to JVMS 4.3.

Added Support for SO_INCOMING_NAPI_ID Support (JDK-8243099)

core-libs/java.net

A new JDK-specific socket option SO_INCOMING_NAPI_ID has been added to
jdk.net.ExtendedSocketOptions in this release. The socket option is Linux
specific and allows applications to query the NAPI (New API) ID of the
underlying device queue associated with its socket connection and take
advantage of the Application Device Queue (ADQ) feature of high performance
Network Interface Card (NIC) devices.

Specialized Implementations of TreeMap Methods (JDK-8176894)

core-libs/java.util:collections

The TreeMap class now provides overriding implementations of the putIfAbsent,
computeIfAbsent, computeIfPresent, compute, and merge methods. The new
implementations provide a performance improvement. However, if the function
provided to the compute- or merge methods modifies the map,
ConcurrentModificationException may be thrown, because the function that is
provided to these methods is prohibited from modifying the map. If a
ConcurrentModificationException occurs, the function must either be changed to
avoid modifying the map, or the surrounding code should be rewritten to replace
uses of the compute- and merge methods with conventional Map methods such as
get and put.

See JDK-8227666 for further information.

Added Ability to Configure Third Port for Remote JMX (JDK-8234484)

core-svc/javax.management

JMX supports (explicit) remote network access through the configuration of two
network ports (either from the command line or in a property file), by setting
the following properties:

com.sun.management.jmxremote.port=<port#>
com.sun.management.jmxremote.rmi.port=<port#>

Note: If it is not specified, the second port will default to the first.

A third local port is also opened to accept (local) JMX connections. This port
previously had its number selected at random, which could cause port
collisions.

However, it is now possible to configure the third JMX port (local only) by
using:
com.sun.management.jmxremote.local.port=<port#>

New Option Added to jstatd for Specifying RMI Connector Port Number (
JDK-8196729)

core-svc/tools

A new -r <port> option has been added to the jstatd command to specify the RMI
connector port number. If a port number is not specified, a random available
port is used.

New Option Added to jcmd for Writing a gzipped Heap Dump (JDK-8237354)

core-svc/tools

A new integer option gz has been added to the GC.heap_dump diagnostic command.
If it is specified, it will enable the gzip compression of the written heap
dump. The supplied value is the compression level. It can range from 1
(fastest) to 9 (slowest, but best compression). The recommended level is 1.

JEP 378: Text Blocks (JDK-8236934)

Text blocks have been added to the Java language. A text block is a multi-line
string literal that avoids the need for most escape sequences, automatically
formats the string in a predictable way, and gives the developer control over
the format when desired.

New Options Added to jhsdb for debugd Mode (JDK-8196751)

hotspot/svc-agent

Three new options have been added to the jhsdb command for the debugd mode:

 1. --rmiport <port> is used to specify a RMI connector port number. If a port
    number is not specified, a random available port is used.
 2. --registryport <port> is used to specify a RMI registry port number. This
    option overrides the system property sun.jvm.hotspot.rmi.port. If a port
    number is not specified, the system property is used. If the system
    property is not set, the default port 1099 is used.
 3. --hostname <hostname> is used to specify a RMI connector host name. The
    value could be a hostname or an IPv4/IPv6 address. This option overrides
    the system property java.rmi.server.hostname. If a host name not specified,
    the system property is used. If the system property is not set, a system
    host name is used.

Added Revocation Checking to jarsigner (JDK-8242060)

security-libs/java.security

A new -revCheck option has been added to the jarsigner command to enable
revocation checking of certificates.

Tools Warn If Weak Algorithms Are Used Before Restricting Them (JDK-8172404)

security-libs/java.security

The keytool and jarsigner tools have been updated to warn users about weak
cryptographic algorithms being used before they are disabled. In this release,
the tools issue warnings for the SHA-1 hash algorithm and 1024-bit RSA/DSA
keys.

SunJCE Provider Supports SHA-3 Based Hmac Algorithms (JDK-8172680)

security-libs/javax.crypto

The SunJCE provider has been enhanced to support HmacSHA3-224, HmacSHA3-256,
HmacSHA3-384, and HmacSHA3-512. Implementations for these algorithms are
available under the Mac and KeyGenerator services. The Mac service generates
the keyed-hash and the KeyGenerator service generates the key for the Mac.

New System Properties to Configure the TLS Signature Schemes (JDK-8242141)

security-libs/javax.net.ssl

Two new system properties have been added to customize the TLS signature
schemes in JDK. jdk.tls.client.SignatureSchemes has been added for the TLS
client side, and jdk.tls.server.SignatureSchemes has been added for the server
side.

Each system property contains a comma-separated list of supported signature
scheme names specifying the signature schemes that could be used for the TLS
connections.

The names are described in the "Signature Schemes" section of the Java \ 
Security
Standard Algorithm Names Specification.

Support for certificate_authorities Extension (JDK-8206925)

security-libs/javax.net.ssl

The "certificate_authorities" extension is an optional extension \ 
introduced in
TLS 1.3. It is used to indicate the certificate authorities (CAs) that an
endpoint supports and should be used by the receiving endpoint to guide
certificate selection.

With this JDK release, the "certificate_authorities" extension is \ 
supported for
TLS 1.3 in both the client and the server sides. This extension is always
present for client certificate selection, while it is optional for server
certificate selection.

Applications can enable this extension for server certificate selection by
setting the jdk.tls.client.enableCAExtension system property to true. The
default value of the property is false.

Note that if the client trusts more CAs than the size limit of the extension
(less than 2^16 bytes), the extension is not enabled. Also, some server
implementations do not allow handshake messages to exceed 2^14 bytes.
Consequently, there may be interoperability issues when
jdk.tls.client.enableCAExtension is set to true and the client trusts more CAs
than the server implementation limit.

Support for canonicalize in krb5.conf (JDK-8239385)

security-libs/org.ietf.jgss:krb5

The 'canonicalize' flag in the krb5.conf file is now supported by the JDK
Kerberos implementation. When set to true, RFC 6806 name canonicalization is
requested by clients in TGT requests to KDC services (AS protocol). Otherwise,
and by default, it is not requested.

The new default behavior is different from JDK 14 and previous releases where
name canonicalization was always requested by clients in TGT requests to KDC
services (provided that support for RFC 6806 was not explicitly disabled with
the sun.security.krb5.disableReferrals system or security properties).

Removed Features and Options

This section describes the APIs, features, and options that were removed in
Java SE 15 and JDK 15. The APIs described here are those that are provided with
the Oracle JDK. It includes a complete implementation of the Java SE 15
Platform and additional Java APIs to support developing, debugging, and
monitoring Java applications. Another source of information about important
enhancements and new features in Java SE 15 and JDK 15 is the Java SE 15 ( JSR
390) Platform Specification, which documents changes to the specification made
between Java SE 14 and Java SE 15. This document includes the identification of
removed APIs and features not described here. The descriptions below might also
identify potential compatibility issues that you could encounter when migrating
to JDK 15. See CSRs Approved for JDK 15 for the list of CSRs closed in JDK 15.

Removal of Terminally Deprecated Solaris-specific SO_FLOW_SLA Socket Option (
JDK-8244582)

core-libs/java.net

In this release, in conjunction with the removal of the Solaris port in JEP 381
, the JDK-specific socket option jdk.net.ExtendedSocketOptions.SO_FLOW_SLA,
which is only relevant to sockets on Solaris, and its supporting classes
SocketFlow and SocketFlow.Status, have been removed.

Removal of RMI Static Stub Compiler (rmic) (JDK-8225319)

core-libs/java.rmi

The RMI static stub compiler rmic has been removed. The rmic tool is obsolete
and has been deprecated for removal since JDK 13.

Removal of Deprecated Constant RMIConnectorServer.CREDENTIAL_TYPES (JDK-8213222
)

core-svc/javax.management

The terminally deprecated constant
javax.management.remote.rmi.RMIConnectorServer.CREDENTIAL_TYPE has been
removed. A filter pattern can be specified instead by using
RMIConnectorServer.CREDENTIALS_FILTER_PATTERN.

Removal of Nashorn JavaScript Engine (JDK-8236933)

The Nashorn JavaScript script engine, its APIs, and the jjs tool have been
removed. The engine, the APIs, and the tool were deprecated for removal in Java
11 with the express intent to remove them in a future release.

Obsolete -XX:UseAdaptiveGCBoundary (JDK-8228991)

hotspot/gc

The VM option UseAdaptiveGCBoundary is obsolete. Use of this option will
produce an obsolete option warning but will otherwise be ignored.

This option was previously disabled by default, and enabling it only had an
effect when also using -XX:+UseParallelGC. Enabling it was intended to provide
a performance benefit for some applications. However, it has been disabled by
default for a long time because of crashes and performance regressions.

Removal of DocuSign Root CA Certificate (JDK-8225068)

security-libs/java.security

The following expired DocuSign root CA certificate has been removed from the
cacerts keystore:

+ alias name "keynectisrootca [jdk]"

  Distinguished Name: CN=KEYNECTIS ROOT CA, OU=ROOT, O=KEYNECTIS, C=FR

Removal of Comodo Root CA Certificate (JDK-8225069)

security-libs/java.security

The following expired Comodo root CA certificate has been removed from the
cacerts keystore:

+ alias name "addtrustclass1ca [jdk]"

  Distinguished Name: CN=AddTrust Class 1 CA Root, OU=AddTrust TTP Network, \ 
O=AddTrust AB, C=SE

Removal of com.sun.net.ssl.internal.ssl.Provider Name (JDK-8219989)

security-libs/javax.net.ssl

The legacy SunJSSE provider name, \ 
"com.sun.net.ssl.internal.ssl.Provider" has
been removed and should no longer be used. The "SunJSSE" name should \ 
be used
instead. For example, SSLContext.getInstance("TLS", "SunJSSE").

Retired the Deprecated SSLSession.getPeerCertificateChain() Method
Implementation (JDK-8241039)

security-libs/javax.net.ssl

The implementation of the deprecated SSLSession.getPeerCertificateChain()
method has been removed from the JDK in the SunJSSE provider and the HTTP
client implementation. The default implementation of this method has been
changed to throw UnsupportedOperationException.

SSLSession.getPeerCertificateChain() is a deprecated method and will be removed
in a future release. To mitigate the removal compatibility impact, applications
should use the SSLSession.getPeerCertificates() method instead. For service
providers, please remove this method from the existing implementation, and do
not support this method in any new implementation.

Deprecated Features and Options

Additional sources of information about the APIs, features, and options
deprecated in Java SE 15 and JDK 15 include:

  * The Deprecated API page identifies all deprecated APIs including those
    deprecated in Java SE 15.
  * The Java SE 15 ( JSR 390) specification specification documents changes to
    the specification made between Java SE 14 and Java SE 15 that include the
    identification of deprecated APIs and features not described here.
  * JEP 277: Enhanced Deprecation provides a detailed description of the
    deprecation policy. You should be aware of the updated policy described in
    this document.

You should be aware of the contents in those documents as well as the items
described in this release notes page.

The descriptions of deprecated APIs might include references to the deprecation
warnings of forRemoval=true and forRemoval=false. The forRemoval=true text
indicates that a deprecated API might be removed from the next major release.
The forRemoval=false text indicates that a deprecated API is not expected to be
removed from the next major release but might be removed in some later release.

The descriptions below also identify potential compatibility issues that you
might encounter when migrating to JDK 15. See CSRs Approved for JDK 15 for the
list of CSRs closed in JDK 15.

Deprecated RMI Activation for Removal (JDK-8245068)

core-libs/java.rmi

The RMI Activation mechanism has been deprecated and may be removed in a future
version of the platform. RMI Activation is an obsolete part of RMI that has
been optional since Java 8. It allows RMI server JVMs to be started
("activated") upon receipt of a request from a client, instead of \ 
requiring RMI
server JVMs to be running continuously. Other parts of RMI are not deprecated.
See JEP 385 for further information.

Deprecated NSWindowStyleMaskTexturedBackground (JDK-8240995)

After an upgrade of the macOS SDK used to build the JDK, the behavior of the
apple.awt.brushMetalLook and textured Swing properties has changed. When these
properties are set, the title of the frame is still visible. It is recommended
that the apple.awt.transparentTitleBar property be set to true to make the
title of the frame invisible again. The apple.awt.fullWindowContent property
can also be used.

Please note that Textured window support was implemented by using the
NSTexturedBackgroundWindowMask value of NSWindowStyleMask. However, this was
deprecated in macOS 10.12 along with NSWindowStyleMaskTexturedBackground, which
was deprecated in macOS 10.14.

For additional information, refer to the following documentation:

  * apple.awt.brushMetalLook: https://developer.apple.com/documentation/appkit/
    nstexturedbackgroundwindowmask?language=objc
  * apple.awt.transparentTitleBar: https://developer.apple.com/documentation/
    appkit/nswindow/1419167-titlebarappearstransparent?language=objc
  * apple.awt.fullWindowContent: https://developer.apple.com/documentation/
    appkit/nsfullsizecontentviewwindowmask

Deprecated -XX:ForceNUMA Option (JDK-8243628)

hotspot/gc

The VM option ForceNUMA is deprecated. Use of this option will produce a
deprecation warning. This option will be removed in a future release.

This option has always been disabled by default. It exists to support testing
of NUMA-related code paths when running on a single node / UMA platform.

Disabled Biased-locking and Deprecated Biased-locking Flags (JDK-8231264)

hotspot/runtime

Biased locking has been disabled by default in this release. In addition, the
VM option UseBiasedLocking along with the VM options BiasedLockingStartupDelay,
BiasedLockingBulkRebiasThreshold, BiasedLockingBulkRevokeThreshold,
BiasedLockingDecayTime and UseOptoBiasInlining have been deprecated. The
options will continue to work as intended but will generate a deprecation
warning when they are used.

Biased locking might affect performance on applications that exhibit
significant amounts of uncontended synchronization, such as applications that
rely on older Java Collections APIs that synchronize on every access. Hashtable
and Vector are examples of these APIs. Use -XX:+BiasedLocking on the command
line to re-enable biased locking. Report any significant performance
regressions to Oracle with biased locking disabled.

Disable Native SunEC Implementation by Default (JDK-8237219)

security-libs/javax.crypto

The SunEC crypto provider no longer advertises curves that are not implemented
by using modern formulas and techniques. Arbitrary and named curves, listed at
the bottom of this note, are disabled. Commonly used named curves, secp256r1,
secp384r1, secp521r1, x25519, and x448, remain supported and enabled by SunEC
because they use modern techniques. Applications that still require the
disabled curves from the SunEC provider can re-enable them by setting the
System property jdk.sunec.disableNative to false. For example: java
-Djdk.sunec.disableNative=false ....
If this property is set to any other value, the curves will remain disabled.
Exceptions thrown when the curves are disabled will contain the message Legacy
SunEC curve disabled, followed by the name of the curve. Methods affected by
the change are KeyPair.generateKeyPair(), KeyAgreement.generateSecret(),
Signature.verify(), and Signature.sign(). These methods throw the same
exception class they had before when the curve was not supported.

The following curves are disabled: secp112r1, secp112r2, secp128r1, secp128r2,
secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1,
secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1,
sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1,
sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62
c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62
c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62
prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3,
brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1

Added forRemoval=true to Previously Deprecated ContentSigner APIs (JDK-8242260)

security-libs/jdk.security

The ContentSigner and ContentSignerParameters classes in the com.sun.jarsigner
package support alternative signers and have been deprecated with forRemoval=
true. When the -altsigner or -altsignerpath options are specified, the
jarsigner tool produces a warning that these options are deprecated and will be
removed.

Known Issues

java.net.HttpClient Does Not Override Protocols Specified in SSLContext Default
Parameters (JDK-8239594)

core-libs/java.net

During the setup of new connections, java.net.http.HttpClient now uses the
default set of protocols provided by the SSLContext when negotiating the TLS
handshake. In the absence of any SSLParameters explicitly supplied to the
HttpClient.builder, the HttpClient has been updated to no longer override any
default-selected protocols in the SSLContext. As a result, the actual TLS
version that is negotiated might differ from that of previous releases, or it
might even succeed or fail to negotiate when it previously might not have.

[macos] Support for Notarizing jpackage app-image and dmg (JDK-8237490)

tools/jpackage

jpackage cannot create packages on macOS that are suitable for notarization.

Other Notes

The following notes describe additional changes and information about this
release. In some cases, the following descriptions provide links to additional
detailed information about an issue or a change.

Workaround for Windows GDI API's memory restrictions (JDK-8240654)

client-libs

It has been found that some Windows GDI functions don't support all types of
Java heap memory allocation schemes. This problem can cause repaint issues and
printing bugs. It has been worked around by allocating temporary buffers off
heap.

See: https://support.microsoft.com/en-us/help/4567569/
gdi-apis-may-fail-when-large-pages-or-vad-spanning-is-used

java.awt.Robot.delay() Method Completes With Interrupt Status Set When
Interrupted (JDK-8210231)

client-libs/java.awt

When it is interrupted, the implementation of the java.awt.Robot.delay() method
has been changed to complete with the interrupt status set.

If a thread is interrupted while waiting in the java.awt.Robot.delay() method,
then this method returns immediately with the interrupt status set. If the
interrupted status is already set, this method returns immediately with the
interrupt status set.

Optimized Empty Substring Handling (JDK-8240094)

core-libs/java.lang

The implementation of String.substring and related methods stripLeading and
stripTrailing have changed in this release to avoid redundantly creating a new
empty String. This may impact code that depends on unspecified behaviour and
the identity of empty sub-strings.

Lookup::defineClass Links the Class (JDK-8238195)

core-libs/java.lang.invoke

Lookup::defineClass is specified to throw LinkageError if a linkage error
occurs, but the implementation was not actually linking the class. In this
release, the implementation has been changed to link the class before
returning, so conforming to the specification. If Lookup::defineClass is called
to define a class that fails linking, LinkageError will be thrown.

DatagramPacket.getPort() Returns 0 When the Port Is Not Set (JDK-8237890)

core-libs/java.net

In this release, the default port number for a datagram packet has been changed
to 0. Previously, this value was -1, which was undocumented. The port can be
retrieved by using DatagramPacket::getPort.

DatagramSocket::disconnect Allows an Implementation to Throw
UncheckedIOException (JDK-8235783)

core-libs/java.net

Previously, DatagramChannel::disconnect threw an IOException while
DatagramSocket::disconnect did not. As a result, the DatagramChannel::socket
adapter, which calls DatagramChannel::disconnect, catches the thrown
IOException and rethrows it as an Error. However, this was undocumented
behavior and not user-friendly.

The DatagramChannel::socket adapter has been changed to throw an
UncheckedIOException, and the specification of DatagramSocket::disconnect has
been updated to document that an implementation may now throw an
UncheckedIOException. This ensures consistency in behavior between
DatagramSocket, DatagramChannel, and DatagramChannel::socket adapter.

Filtering and Ordering of Addresses Returned by Alternative Hosts File Name
Service Provider (JDK-8244958)

core-libs/java.net

In this release, the behavior of InetAddress.getAllByName has been modified
when the alternative hosts file name service is selected .

The JDK allows specifying an alternative host's file name service by using the
jdk.net.hosts.file system property. The implementation of the alternative name
service has been changed to take into account the values of the
java.net.preferIPv4Stack and java.net.preferIPv6Addresses system properties.
This affects the results returned by InetAddress.getAllByName when the host's
file name service is selected. For details about java.net.preferIPv4Stack and
java.net.preferIPv6Addresses, see Networking Properties in the API
documentation.

Modified the MS950 charset Encoder's Conversion Table (JDK-8232161)

core-libs/java.nio.charsets

In this release, some of the one-way byte-to-char mappings have been aligned
with the preferred mappings provided by the Unicode Consortium.

Support Monetary Grouping Separator in DecimalFormat/DecimalFormatSymbols (
JDK-8227313)

core-libs/java.text

DecimalFormat/DecimalFormatSymbols classes are now capable of dealing with
grouping separators for currency values. For example, the monetary grouping
separator for the German language used in Austria (the de-AT locale) is '.',
whereas the monetary grouping separator in other German locales is ' '.

ValueRange.of(long, long, long) Does Not Throw IAE on Invalid Inputs (
JDK-8239520)

core-libs/java.time

java.time.temporal.ValueRange.of() methods are now correctly throwing an
InvalidArgumentException on given invalid arguments. For example, of(5, 2, 10)
which is invalid because the minimum is greater than the smallest maximum, now
throws the exception.

localizedBy() Overrides Localized Values With Default Values (JDK-8244245)

core-libs/java.time

java.time.format.DateTimeFormatter.localizedBy(Locale) method now honors the
default locale values, such as Chronologyand/or DecimalStyle of the specified
locale argument.

For example, in previous JDK releases:

jshell> DateTimeFormatter.ofLocalizedDate(FormatStyle.FULL)
    .localizedBy(Locale.forLanguageTag("fa"))
    .format(LocalDate.now())
$3 ==> "جمعه 1 مهٔ 2020"

the numbers are in Arabic (Western) numerals.

In JDK 15:

jshell> DateTimeFormatter.ofLocalizedDate(FormatStyle.FULL)
    .localizedBy(Locale.forLanguageTag("fa"))
    .format(LocalDate.now())
$3 ==> "جمعه ۱ مهٔ ۲۰۲۰"

the numbers are in Extended Arabic-Indic numerals because it is the default
numbering system for the Farsi locale.

Performance Improvement for InflaterOutputStream.write (JDK-8242848)

core-libs/java.util.jar

InflaterOutputStream(OutputStream out, Inflater infl, int bufLen) allows for
specifying the decompressor and buffer size to be used.

InflaterOutputStream.write(byte[] b, int off, int len) was writing data using a
max buffer size of 512 bytes.

Starting with JDK 15 the buffer size specified via InflaterOutputStream
(OutputStream out, Inflater infl, int bufLen) will be used in calls to
InflaterOutputStream.write(byte[] b, int off, int len). If the buffer size is
not specified when invoking the InflaterOutputStreamconstructor, it will
default to 512 bytes.

Case Insensitive Matching Doesn't Work Correctly for Some Character Classes (
JDK-8214245)

core-libs/java.util.regex

The Java regular expression engine supports the case insensitive mode. When
this mode is turned on, the engine is supposed to match the input text without
regard to the case of the characters it consists of.

However, the current implementation of matching against some named character
classes (those that are encoded with p{name} or P{name} constructs) fails to
respect the case insensitive mode.

This fix makes these character classes behave consistently with respect to case
sensitivity. When the regular expression engine operates in the case
insensitive mode, the named character classes will match the input characters
without regard to their case: lower case, upper case, or title case.

Localized Time Zone Name Inconsistency Between English and Other Locales (
JDK-8236548)

core-libs/java.util:i18n

English time zone names provided by the CLDR locale provider are now correctly
synthesized following the CLDR spec, rather than substituted from the COMPAT
provider. For example, SHORT style names are no longer synthesized
abbreviations of LONG style names, but instead produce GMT offset formats.

Support for CLDR version 37 (JDK-8239480)

core-libs/java.util:i18n

Locale data based on Unicode Consortium's CLDR has been upgraded to their
version 37. For the detailed locale data changes, please refer to the Unicode
Consortium's CLDR release notes:

  * http://cldr.unicode.org/index/downloads/cldr-37

Flags Controlling C1 Inlining Have New Names (JDK-8235673)

hotspot/compiler

A number of flags controlling inlining in the C1 and C2 compilers have been
split up into separate flags. The C2 compiler keeps the flags with the old
names, and the C1 compiler gets the new flags.

Old flags now only controlling C2

  * MaxInlineLevel
  * MaxRecursiveInlineLevel
  * MaxInlineSize
  * MaxTrivialSize
  * InlineSmallCode
  * FreqInlineSize

New flags for C1 that replace the old ones

  * C1MaxInlineLevel
  * C1MaxRecursiveInlineLevel
  * C1MaxInlineSize
  * C1MaxTrivialSize

Deprecation

If the old flags are used in a JDK build without the C2 compiler, a deprecation
warning will be printed.

JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production) (
JDK-8209683)

hotspot/gc

The Z Garbage Collector (ZGC) is now ready for use in production and no longer
marked as an experimental feature. ZGC is enabled by using the -XX:+UseZGC
command-line option (using -XX:+UnlockExperimentalVMOptions is no longer
needed).

See JEP 377 for more details.

Improved Ergonomics for G1 Heap Region Size (JDK-8241670)

hotspot/gc

The default heap region size calculation has been changed to return larger
regions by default. The calculation still aims to have 2048 regions, but two
aspects have changed:

  * Only the maximum heap size is considered. The old calculation also took the
    initial heap size into consideration, but this can give unexpected behavior
    when no heap size is set.
  * The region size is rounded up to the nearest power of 2 instead of down.
    This will return larger region sizes in cases where the maximum heap size
    is not a power of 2.

These changes improve startup and runtime performance.

Disabling NUMA Interleaving on Windows (JDK-8245002)

hotspot/gc

-XX:+UseNUMAInterleaving has no effect on Windows in this release. It was found
that GDI APIs used by java2d don't support the memory reservation scheme used
for NUMA interleaving. The JVM detects this problem and both warns about this
and turns off NUMA interleaving. See: https://support.microsoft.com/en-us/help/
4567569/gdi-apis-may-fail-when-large-pages-or-vad-spanning-is-used

Disabling large pages on Windows (JDK-8245000)

hotspot/gc

-XX:+UseLargePages has no effect on Windows in this release. It was found that
GDI APIs used by java2d don't support large pages. The JVM detects this problem
and both warns about this and reverts to using small pages. See: https://
support.microsoft.com/en-us/help/4567569/
gdi-apis-may-fail-when-large-pages-or-vad-spanning-is-used

Field Layout Computation Changed (JDK-8237767)

hotspot/runtime

The way that field layout is computed has been changed, with more aggressive
optimizations to avoid unused gaps in instances. These new optimizations can be
disabled by using a new VM option -XX:-UseEmptySlotsInSupers.

For a limited time, it is possible to continue to use the old code to compute
field layout with a new VM option -XX:-UseNewFieldLayout. However, this option
has been deprecated in JDK 15 and the old code will be removed in a future
release.

Enable ShowCodeDetailsInExceptionMessages by default (JDK-8233014)

hotspot/runtime

The default of the flag ShowCodeDetailsInExceptionMessages was changed to
'true'. The helpful NullPointerException messages of JEP 358 are now printed by
default. The messages contain snippets of the code where the
NullPointerException was raised.

App deployers should double check the output of their web applications and
similar usage scenarios. The NullPointerException message could be included in
application error messages or be displayed by other means in the app. This
could give remote attackers valuable hints about a potential vulnerable state
of the software components being used.

An example message is 'Cannot read field "c" because "a.b" \ 
is null'. The
attacker knows that field b of a contains null which might be unintended and
offer an opportunity for an attack. For more details of what the message can
contain see the above mentioned JEP 358.

Signature and SignatureSpi Get Parameter Methods May Return null When
Unsupported (JDK-8243424)

security-libs/java.security

Signature.getParameters() and SignatureSpi.engineGetParameters() may return
null if the underlying provider does not support returning the parameters as
AlgorithmParameters. For further details, see the Signature and SignatureSpi
method descriptions.

SunPKCS11 Initialization With NSS When External FIPS Modules Are in Security
Modules Database (JDK-8238555)

security-libs/javax.crypto:pkcs11

The SunPKCS11 security provider can now be initialized with NSS when
FIPS-enabled external modules are configured in the Security Modules Database
(NSSDB). Before this change, when such a library was configured for NSS in
non-FIPS mode, the SunPKCS11 provider would throw a RuntimeException with the
message "FIPS flag set for non-internal module".

This change allows the JDK to work properly with recent NSS releases in GNU/
Linux operating systems when the system-wide FIPS policy is turned on.

Default SSLEngine Should Create in Server Role (JDK-8237474)

security-libs/javax.net.ssl

In JDK 11 and later, javax.net.ssl.SSLEngine by default used client mode when
handshaking. As a result, the set of default enabled protocols may differ to
what is expected. SSLEngine would usually be used in server mode. From this JDK
release onwards, SSLEngine will default to server mode. The
javax.net.ssl.SSLEngine.setUseClientMode​(boolean mode) method may be used to
configure the mode.