JDK 17 Early-Access Release Notes

This is a draft of the release notes that will accompany JDK 17. The contents are subject to change until release.

Build 26

SunJCE provider now supports KW and KWP modes with AES cipher (JDK-8248268)

security-libs/javax.crypto

The SunJCE provider has been enhanced to support the AES Key Wrap Algorithm (RFC 3394) and the AES Key Wrap with Padding Algorithm (RFC 5649). In earlier releases, the SunJCE provider supports RFC 3394 under the "AESWrap" cipher algorithm which can only be used to wrap and unwrap keys. With this enhancement, it adds two block cipher modes KW and KWP that support data encryption/decryption and key wrap/unwrap using AES. Please check the "SunJCE provider" section of the "JDK Providers Documentation" guide for more details.

Parallel GC Enables Adaptive Parallel Reference Processing by Default (JDK-8204686)

hotspot/gc

Parallel GC now ergonomically determines the optimal number of threads to use for processing java.lang.ref.Reference instances during garbage collection. The option -XX:ParallelRefProcEnabled is now true (enabled) by default.

The change improves this phase of the garbage collection pause significantly on machines with more than one thread available for garbage collection.

If you experience increased garbage collection pauses, you can revert to the original behavior by specifying -XX:-ParallelRefProcEnabled on the command line.

The ergonomics of java.lang.ref.Reference processing can be tuned by using the experimental option -XX:ReferencesPerThread (default value: 1000).

Build 25

ISO 639 language codes for Hebrew/Indonesian/Yiddish (JDK-8263202)

core-libs/java.util:i18n

Historically, Java has been using old/obsolete ISO 639 language codes for those languages for compatibility. From Java 17, they default to the current codes. For example, "he" is now the language code for "Hebrew" instead of "iw". A new system property has also been introduced to revert to the legacy behavior. If -Djava.locale.useOldISOCodes=true is specified on the command line, it behaves the same way as the prior releases.

Unified Logging now supports asynchronous log flushing (JDK-8229517)

hotspot/runtime

To avoid undesirable delays in a thread using unified logging, the user can now request that the unified logging system operate in asynchronous mode. This is done by passing the command-line option -Xlog:async. In asynchronous logging mode, log sites enqueue all logging messages to a buffer and a standalone thread is responsible for flushing them to the corresponding outputs. The intermediate buffer is bounded. On buffer exhaustion the enqueuing message is discarded. The user can control the size of the intermediate buffer using the command-line option -XX:AsyncLogBufferSize=<bytes>.

JEP 403: Strongly Encapsulate JDK Internals (JDK-8266851)

core-libs

Strongly encapsulate all internal elements of the JDK, except for critical internal APIs such as sun.misc.Unsafe.

With this change, the java launcher option --illegal-access is obsolete. If used on the command line it causes a warning message to be issued, and otherwise has no effect. Existing code that must use internal classes, methods, or fields of the JDK can still be made to work by using the --add-opens launcher option, or the Add-Opens JAR-file manifest attribute, to open specific packages.

For further details, please see JEP 403.

Build 23

Removal of sun.misc.Unsafe::defineAnonymousClass (JDK-8243287)

core-libs

sun.misc.Unsafe::defineAnonymousClass API has been removed in JDK 17. The API replacement is java.lang.invoke.MethodHandles.Lookup::defineHiddenClass and java.lang.invoke.MethodHandles.Lookup::defineHiddenClassWithClassData.

Build 22

New implementation of java.nio.channels.Selector on Microsoft Windows (JDK-8266369)

core-libs/java.nio

The Windows implementation of the java.nio.channels.Selector API has been replaced in this release to use a new more scalable implementation. No behavior or compatibility issues were observed during testing of the new implementation. The old implementation has not been removed and the JDK can be configured to use the old implementation, if needed, by running with -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.WindowsSelectorProvider on the command line.

Build 21

macOS on ARM early access available (JDK-8266858)

infrastructure/build

A new macOS is now available for ARM systems. The ARM port should behave similarly to the Intel port. There are no known feature differences. When reporting issues on macOS please specify if using ARM or x64.

System property for the native character encoding name (JDK-8265989)

core-libs/java.lang

A new system property native.encoding has been introduced. This system property provides the underlying host environment's character encoding name. For example, typically it has UTF-8 in Linux and macOS platforms, and Cp1252 in Windows (en-US). Refer to the CSR for more detail.

Disable SHA-1 JARs (JDK-8196415)

security-libs/java.security

JARs signed with SHA-1 algorithms are now restricted by default and treated as if they were unsigned. This applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have been revoked.

In order to reduce the compatibility risk for applications that have been previously timestamped or use private CAs, there are two exceptions to this policy:

  • Any JAR signed with SHA-1 algorithms and timestamped prior to January 01, 2019 will not be restricted.
  • Any JAR signed with a SHA-1 certificate that does not chain back to a Root CA included by default in the JDK cacerts keystore will not be restricted.

These exceptions may be removed in a future JDK release.

Users can, at their own risk, remove these restrictions by modifying the java.security configuration file (or overriding it using the java.security.properties system property) and removing "SHA1 jdkCA & usage SignedJAR & denyAfter 2019-01-01" from the jdk.certpath.disabledAlgorithms security property and "SHA1 jdkCA & denyAfter 2019-01-01" from the jdk.jar.disabledAlgorithms security property.

Build 20

Console charset API (JDK-8264208)

core-libs

java.io.Console has been updated to define a new method that returns the Charset for the console. The returned Charset may be different from the one returned from Charset.defaultCharset() method. For example, it returns IBM437 while Charset.defaultCharset() returns windows-1252 on Windows (en-US). Refer to the CSR for more detail.

Build 19

Support for CLDR Version 39 (JDK-8258794)

core-libs/java.util:i18n

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

Build 18

Provide the support for specifying a signer in keytool -genkeypair command (JDK-8260693)

security-libs/java.security

The -signer and -signerkeypass options have been added to the -genkeypair command of the keytool utility. The -signer option specifies the keystore alias of a PrivateKeyEntry for the signer and the -signerkeypass option specifies the password used to protect the signer’s private key. These options allow keytool -genkeypair to sign the certificate using the signer’s private key. This is especially useful for generating a certificate with a key agreement algorithm as its public key algorithm.

Build 13

Collections.unmodifiable* methods are idempotent for their corresponding collection. (JDK-6323374)

core-libs/java.util:collections

The unmodifiable* methods in java.util.Collections will no longer re-wrap a given collection with an unmodifiable view if that collection has already been wrapped by same method.

Disable SHA-1 XML Signatures (JDK-8259709)

security-libs/javax.xml.crypto

XML signatures that use SHA-1 based digest or signature algorithms have been disabled by default. SHA-1 is no longer a recommended algorithm for digital signatures. If necessary, and at their own risk, applications can workaround this policy by modifying the jdk.xml.dsig.secureValidationPolicy security property and re-enabling the SHA-1 algorithms.

Build 12

Deprecate 3DES and RC4 in Kerberos (JDK-8139348)

security-libs/org.ietf.jgss:krb5

The des3-hmac-sha1 and rc4-hmac Kerberos encryption types (etypes) are now deprecated and disabled by default. Users can set "allow_weak_crypto = true" in the krb5.conf configuration file to re-enable them (along with other weak etypes including des-cbc-crc and des-cbc-md5) at their own risk. To disable a subset of the weak etypes, users can list preferred etypes explicitly in any of default_tkt_enctypes, default_tgs_enctypes, or permitted_enctypes settings.

Build 11

Updated keytool to create AKID from the SKID of the issuing certificate as specified by RFC 5280 (JDK-8257497)

security-libs/java.security

The gencert command of the keytool utility has been updated to create AKID from the SKID of the issuing certificate as specified by RFC 5280.

Build 10

Deprecate the socket impl factory mechanism (JDK-8235139)

core-libs/java.net

The following static methods to set the system-wide socket implementation factories have been deprecated:

  • static void ServerSocket.setSocketFactory​(SocketImplFactory fac)
  • static void Socket.setSocketImplFactory​(SocketImplFactory fac)
  • static void DatagramSocket.setDatagramSocketImplFactory​(DatagramSocketImplFactory fac)

These API points were used to statically configure a system-wide factory for the corresponding socket types in the java.net package. These methods have mostly been obsolete since Java 1.4.

Build 9

Removed Telia Company's Sonera Class2 CA certificate (JDK-8225081)

security-libs/java.security

The following root certificate has been removed from the cacerts truststore:

+ Telia Company
  + soneraclass2ca
    DN: CN=Sonera Class2 CA, O=Sonera, C=FI

Build 8

Added 2 HARICA Root CA Certificates (JDK-8256421)

security-libs/java.security

The following root certificates have been added to the cacerts truststore:

+ HARICA
  + haricarootca2015
    DN: CN=Hellenic Academic and Research Institutions RootCA 2015, O=Hellenic Academic and Research Institutions Cert. Authority, L=Athens, C=GR

  + haricaeccrootca2015
    DN: CN=Hellenic Academic and Research Institutions ECC RootCA 2015, O=Hellenic Academic and Research Institutions Cert. Authority, L=Athens, C=GR

Enable XML Signature secure validation mode by default (JDK-8259801)

security-libs/javax.xml.crypto

The XML Signature secure validation mode has been enabled by default (previously it was not enabled by default unless running with a security manager). When enabled, validation of XML signatures are subject to stricter checking of algorithms and other constraints as specified by the jdk.xml.dsig.secureValidationPolicy security property.

If necessary, and at their own risk, applications can disable the mode by setting the org.jcp.xml.dsig.secureValidation property to Boolean.FALSE with the DOMValidateContext.setProperty() API.

Configurable extensions with system properties (JDK-8217633)

security-libs/javax.net.ssl

Two new system properties have been added. The system property, "jdk.tls.client.disableExtensions", is used to disable TLS extensions used in the client. The system property, "jdk.tls.server.disableExtensions", is used to disable TLS extensions used in the server. If an extension is disabled, it will be neither produced nor processed in the handshake messages.

The property string is a list of comma separated standard TLS extension names, as registered in the IANA documentation (for example, server_name, status_request and signature_algorithms_cert). Note that the extension names are case sensitive. Unknown, unsupported, misspelled and duplicated TLS extension name tokens will be ignored.

Please note that the impact of blocking TLS extensions is complicated. For example, a TLS connection may not be able to be established if a mandatory extension is disabled. Please do not disable mandatory extensions, and do not use this feature unless you clearly understand the impact.

Build 7

New system property to enable the OCSP Nonce Extension (JDK-8256895)

security-libs/java.security

A new system property jdk.security.certpath.ocspNonce has been added to enable the OCSP Nonce Extension. This system property is disabled by default, and can be enabled by setting it to the value true. If set to true, the JDK implementation of PKIXRevocationChecker includes a nonce extension containing a 16 byte nonce with each OCSP request. See RFC 8954 for more details on the OCSP Nonce Extension.

Build 6

TreeMap.computeIfAbsent Mishandles Existing Entries Whose Values Are null (JDK-8259622)

core-libs/java.util:collections

Enhancement JDK-8176894 inadvertently introduced erroneous behavior in the TreeMap.computeIfAbsent method. The other TreeMap methods that were modified by this enhancement are unaffected. The erroneous behavior is that, if the map contains an existing mapping whose value is null, the computeIfAbsent method immediately returns null. To conform with the specification, computeIfAbsent should instead call the mapping function and update the map with the function's result.

jarsigner tool warns if weak algorithms are used in signer’s certificate chain (JDK-8259401)

security-libs/java.security

The jarsigner tool has been updated to warn users when weak keys or cryptographic algorithms are used in certificates of the signer’s certificate chain.

Build 3

Clarify the Specification of KeyStoreSpi.engineStore(KeyStore.LoadStoreParameter) and in KeyStore.store(KeyStore.LoadStoreParameter) Methods (JDK-8246005)

security-libs/java.security

The specifications of the KeyStoreSpi.engineStore(KeyStore.LoadStoreParameter param) and KeyStore.store(KeyStore.LoadStoreParameter param) methods have been updated to specify that an UnsupportedOperationException is thrown if the implementation does not support the engineStore() operation. This change adjusts the specification to match the existing behavior.

Not Yet Integrated

Modernization of Ideal Graph Visualizer (JDK-8254145)

hotspot/compiler

Ideal Graph Visualizer (IGV), a tool to explore visually and interactively the intermediate representation used in the HotSpot VM C2 just-in-time (JIT) compiler, has been modernized. Enhancements include:

  • support for running IGV on up to JDK 15 (the latest version supported by IGV's underlying NetBeans Platform);
  • a faster, Maven-based IGV build system;
  • stabilization of block formation, group removal, and node tracking;
  • more intuitive coloring and node categorization in default filters; and
  • ranked quick node search with more natural default behavior.

The modernized IGV is partially compatible with graphs generated from earlier JDK releases: it supports basic functionality such as graph loading and visualization, but auxiliary functionality such as node clustering and coloring might be affected.

Details about building and running IGV are available in the src/utils/IdealGraphVisualizer/README.md file in the tool's source directory.

Delivered

JEP 410: Remove The Experimental AOT and JIT Compiler (JDK-8263327)

hotspot/compiler

AOT Compiler related code in HotSpot VM has been removed. Using HotSpot VM options defined by JEP295 produce "Unrecognized VM option" error on VM initialization.

URL FTP Protocol Handler: IPv4 Address Validation in Passive Mode (JDK-8258432)

core-libs/java.net

Client-side FTP support in the Java platform is available through the FTP URL stream protocol handler, henceforth referred to as the FTP Client.

The following system property has been added for validation of server addresses in FTP passive mode.

  • jdk.net.ftp.trustPasvAddress.

In this release, the FTP Client has been enhanced to reject an address sent by a server, in response to a PASV command from the FTP Client, when that address differs from the address which the FTP Client initially connected.

To revert to the prior behavior, the jdk.net.ftp.trustPasvAddress system property can be set to true. The affect of setting this property is that the FTP Client accepts and uses the address value returned in reply to a PASV command

XML implementation specific features and properties (JDK-8261856)

Documentation for Implementation Specific Features and Properties has been added to the java.xml module summary. Along with the existing properties, two new properties are introduced in JDK 17. The following section describes the changes in more detail.

  1. Add javadoc for the XML processing limits

    XML processing limits were introduced in JDK 7u45 and 8. They were previously documented in the Java Tutorial Processing Limits section.

    The definitions for these limits have been added to the module summary. See JDK-8261670.

  2. Move the javadoc for JAXP Lookup Mechanism to module summary

    The javadoc for JAXP Lookup Mechanism has been moved to the module summary. The original javadocs in JAXP factories are replaced with a link to that in the module summary.

    See JDK-8261673.

  3. Add a property to control newline after XML header for DOM LSSerializer

    The DOM Load and Save LSSerializer did not have an explicit control for whether or not the XML Declaration ends with a newline. In this release, a JDK implementation specific property jdk.xml.isStandalone and its corresponding System property jdk.xml.isStandalone have been added to control the addition of a newline and acts independently without having to set the pretty-print property. This property can be used to reverse the incompatible change introduced in Java SE 7 Update 4 with an update of Xalan 2.7.1 where a newline is omitted after the XML header.

    Usage:

    // to set the property, get an instance of LSSerializer
    LSSerializer ser = impl.createLSSerializer();
    // the isStandalone property is effective whether or not pretty-print is set
    ser.getDomConfig().setParameter("format-pretty-print", pretty ? true : false);
    ser.getDomConfig().setParameter("jdk.xml.isStandalone", standalone ? true : false);

    // to use the System property, set it before initializing a LSSerializer
    System.setProperty("jdk.xml.isStandalone", standalone ? “true” : "false");

    // to clear the property, place the line anywhere after the LSSerializer is initialized
    System.clearProperty("jdk.xml.isStandalone");

See <a HREF="https://bugs.openjdk.java.net/browse/JDK-8249867">JDK-8249867</a>.
  1. Add a property to control newline after XML header for XSLTC Serializer

    The XSLTC Serializer supported a property http://www.oracle.com/xml/is-standalone, introduced through JDK-7150637, to control whether or not the XML Declaration ends with a newline. It is however, not in compliant with the new specification for Implementation Specific Features and Properties. In order to maintain compatibility, the legacy property is preserved, and a new property jdk.xml.xsltcIsStandalone along with its corresponding System property jdk.xml.xsltcIsStandalone have been created to perform the same function for the XSLTC Serializer as the isStandalone property for DOMLS LSSerializer. Note that the former has an extra prefix xsltc to avoid conflict with the later in case it is set through the System property.

    Usage:

    // to set the property, get an instance of the Transformer
    Transformer transformer = getTransformer(…);
    // the isStandalone property is effective whether or not pretty-print is set
    transformer.setOutputProperty(OutputKeys.INDENT, pretty ? "yes" : "no");
    transformer.setOutputProperty("jdk.xml.xsltcIsStandalone", standalone ? "yes" : "no");

    // to use the System property, set it before initializing a Transformer
    System.setProperty("jdk.xml.xsltcIsStandalone", standalone ? "yes" : "no");

    // to clear the property, place the line anywhere after the Transformer is initialized
    System.clearProperty("jdk.xml.xsltcIsStandalone");

See <a HREF="https://bugs.openjdk.java.net/browse/JDK-8260858">JDK-8260858</a>.
  1. Add existing features and properties and standardizing the prefix to jdk.xml

    Existing features and properties have been added to the Implementation Specific Features and Properties tables in the java.xml module summary. All of the features and properties, existing and new, now have a prefix jdk.xml as redefined in the Naming Convention section. System properties are searchable in the Java API documentation by the full name, such as jdk.xml.entityExpansionLimit.

    See JDK-8265252.

New System and Security Properties to Control Reconstruction of Remote Objects by JDK's Built-in JNDI RMI and LDAP Implementations (JDK-8244473)

core-libs/javax.naming

jdk.jndi.object.factoriesFilter: This system and security property allows a serial filter to be specified that controls the set of object factory classes permitted to instantiate objects from object references returned by naming/directory systems. The factory class named by the reference instance is matched against this filter during remote reference reconstruction. The filter property supports pattern-based filter syntax with the format specified by JEP 290. This property applies both to the JNDI/RMI and the JNDI/LDAP built-in provider implementations. The default value allows any object factory class specified in the reference to recreate the referenced object.

com.sun.jndi.ldap.object.trustSerialData: This system property allows control of the deserialization of java objects from the javaSerializedData LDAP attribute. To prevent deserialization of java objects from the attribute, the system property can be set to false value. By default, deserialization of java objects from the javaSerializedData attribute is allowed.