JDK 12 Early-Access Release Notes

Last Update: 2019/01/18

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

Build 24

Distrust TLS server certificates anchored by Symantec Root CAs (JDK-8207258)

security-libs/javax.net.ssl

The JDK will stop trusting TLS Server certificates issued by Symantec, in line with similar plans recently announced by Google, Mozilla, Apple, and Microsoft. The list of affected certificates includes certificates branded as GeoTrust, Thawte, and VeriSign, which were managed by Symantec.

TLS Server certificates issued before April 16, 2019 will continue to be trusted until they expire. Certificates issued after that date will be rejected. See the DigiCert support page for information on how to replace your Symantec certificates with a DigiCert certificate (DigiCert took over validation and issuance for all Symantec Website Security SSL/TLS certificates on December 1, 2017).

The restrictions are enforced in the JDK implementation (the SunJSSE Provider) of the Java Secure Socket Extension (JSSE) API. A TLS session will not be negotiated if the server's certificate chain is anchored by any of the Certificate Authorities in the table below.

An application will receive an Exception with a message indicating the trust anchor is not trusted, ex:

"TLS Server certificate issued after 2019-04-16 and anchored by a distrusted legacy Symantec root CA: CN=GeoTrust Global CA, O=GeoTrust Inc., C=US"

If necessary, and at your own risk, you can work around the restrictions by removing "SYMANTEC_TLS" from the jdk.security.caDistrustPolicy security property in the java.security configuration file.

The restrictions are imposed on the following Symantec Root certificates included in the JDK:

Root Certificates to be distrusted after 2019-04-16
Distinguished Name SHA-256 Fingerprint
CN=GeoTrust Global CA, O=GeoTrust Inc., C=US

FF:85:6A:2D:25:1D:CD:88:D3:66:56:F4:50:12:67:98:CF:AB:AA:DE:40:79:9C:72:2D:E4:D2:B5:DB:36:A7:3A

CN=GeoTrust Primary Certification Authority, O=GeoTrust Inc., C=US

37:D5:10:06:C5:12:EA:AB:62:64:21:F1:EC:8C:92:01:3F:C5:F8:2A:E9:8E:E5:33:EB:46:19:B8:DE:B4:D0:6C

CN=GeoTrust Primary Certification Authority - G2, OU=(c) 2007 GeoTrust Inc. - For authorized use only, O=GeoTrust Inc., C=US

5E:DB:7A:C4:3B:82:A0:6A:87:61:E8:D7:BE:49:79:EB:F2:61:1F:7D:D7:9B:F9:1C:1C:6B:56:6A:21:9E:D7:66

CN=GeoTrust Primary Certification Authority - G3, OU=(c) 2008 GeoTrust Inc. - For authorized use only, O=GeoTrust Inc., C=US

B4:78:B8:12:25:0D:F8:78:63:5C:2A:A7:EC:7D:15:5E:AA:62:5E:E8:29:16:E2:CD:29:43:61:88:6C:D1:FB:D4

CN=GeoTrust Universal CA, O=GeoTrust Inc., C=US

A0:45:9B:9F:63:B2:25:59:F5:FA:5D:4C:6D:B3:F9:F7:2F:F1:93:42:03:35:78:F0:73:BF:1D:1B:46:CB:B9:12

CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US

8D:72:2F:81:A9:C1:13:C0:79:1D:F1:36:A2:96:6D:B2:6C:95:0A:97:1D:B4:6B:41:99:F4:EA:54:B7:8B:FB:9F

CN=thawte Primary Root CA - G2, OU="(c) 2007 thawte, Inc. - For authorized use only", O="thawte, Inc.", C=US

A4:31:0D:50:AF:18:A6:44:71:90:37:2A:86:AF:AF:8B:95:1F:FB:43:1D:83:7F:1E:56:88:B4:59:71:ED:15:57

CN=thawte Primary Root CA - G3, OU="(c) 2008 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US

4B:03:F4:58:07:AD:70:F2:1B:FC:2C:AE:71:C9:FD:E4:60:4C:06:4C:F5:FF:B6:86:BA:E5:DB:AA:D7:FD:D3:4C

EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA

3F:9F:27:D5:83:20:4B:9E:09:C8:A3:D2:06:6C:4B:57:D3:A2:47:9C:36:93:65:08:80:50:56:98:10:5D:BC:E9

OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 2 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US

3A:43:E2:20:FE:7F:3E:A9:65:3D:1E:21:74:2E:AC:2B:75:C2:0F:D8:98:03:05:BC:50:2C:AF:8C:2D:9B:41:A1

OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US

A4:B6:B3:99:6F:C2:F3:06:B3:FD:86:81:BD:63:41:3D:8C:50:09:CC:4F:A3:29:C2:CC:F0:E2:FA:1B:14:03:05

OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US

83:CE:3C:12:29:68:8A:59:3D:48:5F:81:97:3C:0F:91:95:43:1E:DA:37:CC:5E:36:43:0E:79:C7:A8:88:63:8B

CN=VeriSign Class 3 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US

EB:04:CF:5E:B1:F3:9A:FA:76:2F:2B:B1:20:F2:96:CB:A5:20:C1:B9:7D:B1:58:95:65:B8:1C:B9:A1:7B:72:44

CN=VeriSign Class 3 Public Primary Certification Authority - G4, OU="(c) 2007 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US

69:DD:D7:EA:90:BB:57:C9:3E:13:5D:C8:5E:A6:FC:D5:48:0B:60:32:39:BD:C4:54:FC:75:8B:2A:26:CF:7F:79

CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US

9A:CF:AB:7E:43:C8:D8:80:D0:6B:26:2A:94:DE:EE:E4:B4:65:99:89:C3:D0:CA:F1:9B:AF:64:05:E4:1A:B7:DF

CN=VeriSign Universal Root Certification Authority, OU="(c) 2008 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US

23:99:56:11:27:A5:71:25:DE:8C:EF:EA:61:0D:DF:2F:A0:78:B5:C8:06:7F:4E:82:82:90:BF:B8:60:E8:4B:3C

If you have a TLS Server certificate issued by one of the CAs above, you should have received a message from DigiCert with information about replacing that certificate, free of charge.

You can also use the keytool utility from the JDK to print out details of the certificate chain, as follows:

keytool -v -list -alias <your_server_alias> -keystore <your_keystore_filename>

If any of the certificates in the chain are issued by one of the root CAs in the table above are listed in the output you will need to update the certificate or contact the organization that manages the server if not yours.

Customizing the generation of a PKCS12 keystore (JDK-8076190)

security-libs/java.security

New system and security properties have been added to allow users to customize the generation of PKCS #12 keystores. This includes algorithms and parameters for key protection, certificate protection, and MacData. The detailed explanation and possible values for these properties can be found in the "PKCS12 KeyStore properties" section of the java.security file.

Compact Number Formatting Support (JDK-8177552)

core-libs/java.text

NumberFormat adds support for formatting a number in its compact form. A compact number formatting refers to the representation of a number in a short or human readable form. For example, in the en_US locale, 1000 can be formatted as "1K", and 1000000 as "1M", depending upon the style used, which is specified by NumberFormat.Style. It is defined by LDML's specification for Compact Number Formats. To obtain the instance, use one of the factory methods given by NumberFormat for compact number formatting.

NumberFormat fmt = NumberFormat.getCompactNumberInstance(Locale.US, NumberFormat.Style.SHORT);
String result = fmt.format(1000);

The above example results in "1K".

Build 23

Removed TLS v1 and v1.1 from SSLContext required algorithms (JDK-8214140)

security-libs/javax.net.ssl

The requirement that all SE implementations must support TLSv1 and TLSv1.1 has been removed from the javax.net.ssl.SSLContext API and the Java Security Standard Algorithm Names specification.

Properties.loadFromXML method changed to comply with the specification (JDK-8213325)

core-libs/java.util

The implementation of the java.util.Properties loadFromXML method is changed to comply with its specification. Specifically, the underlying XML parser implementation now rejects non-compliant XML documents by throwing an InvalidPropertiesFormatException as specified by the loadFromXML method.

The effect of the change is as follows:

  • Documents created by Properties.storeToXML: no change. Properties.loadFromXML will have no problem reading such files.

  • Documents not created by Properties.storeToXML: any documents containing DTDs not in the format as specified in Properties.loadFromXML will be rejected. This means the DTD shall be exactly as follows (as generated by the Properties.storeToXML method):

    <!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">

Build 21

Unicode 11 (JDK-8209923)

core-libs/java.lang

The JDK 12 release includes support for Unicode 11.0.0. Since the release of JDK 11, which supported Unicode 10.0.0, the Unicode 11.0.0 introduced the following new features that are now included in JDK 12:

  • 684 new characters
  • 11 new blocks
  • 7 new scripts.

684 new characters include important additions for:

  • 66 emoji characters
  • Copyleft symbol
  • Half stars for rating systems
  • Additional astrological symbols
  • Xiangqi Chinese chess symbols

7 new scripts :

  • Hanifi Rohingya
  • Old Sogdian
  • Sogdian
  • Dogra
  • Gunjala Gondi
  • Makasar
  • Medefaidrin

11 new blocks which include 7 blocks for the new scripts listed above and 4 blocks for the following existing scripts:

  • Georgian Extended
  • Mayan Numerals
  • Indic Siyaq Numbers
  • Chess Symbols

Deprecating the default keytool -keyalg value (JDK-8212003)

security-libs/java.security

The default -keyalg value for the -genkeypair and -genseckey commands of keytool have been deprecated. If a user has not explicitly specified a value for the -keyalg option a warning will be shown. An additional informational text will also be printed showing the algorithm(s) used by the newly generated entry. In a subsequent JDK release, the default key algorithm values will no longer be supported and the -keyalg option will be required.

Change to X25519 and X448 encoded private key format (JDK-8213363)

security-libs/javax.crypto

The encoded format of X25519 and X448 private keys is corrected to use the standard format described in RFC 8410. This change affects any private key produced from the "X25519", "X448", or "XDH" services in the SunEC provider. The correct format is not compatible with the format used in previous JDK versions. It is recommended that existing incompatible keys in storage are replaced with newly-generated private keys.

URLPermission behavior with query or fragments in the URL string (JDK-8213616)

core-libs/java.net

The behavior of java.net.URLPermission has changed slightly. It was previously specified to ignore query and fragment components in the supplied URL string. However, this behavior was not implemented and any query or fragment were included in the internal permission URL string. The change here is to implement the behavior as specified. Internal usages of URLPermission in the JDK do not include queries or fragments. So, this will not change. In the unlikely event that user code was creating URLPermission objects explicitly, then the behavior change may be seen and that permission checks which failed erroneously previously, will now pass as expected.

Build 20

Add -groupname option to keytool keypair generation (JDK-8213400)

security-libs/java.security

A new -groupname option has been added to keytool -genkeypair so a user can specify a named group when generating a key pair. For example, keytool -genkeypair -keyalg EC -groupname secp384r1 will generate an EC key pair using the secp384r1 curve. The -groupname option should be preferred over the -keysize option because there may be multiple curves with the same size.

New command-line flag for more extensive error reporting in crash logs (JDK-8211845)

hotspot/runtime

The command-line flag -XX:+ExtensiveErrorReports has been added to allow more extensive reporting of information relating to a crash as reported in the hs_err<pid>.log file. Disabled by default in product builds, the flag can be turned on in environments where maximal information is desired - even if the resulting logs may be quite large and/or contain information that might be considered sensitive.

Initial Value of user.timezone System Property Changed (JDK-8185496)

core-libs/java.lang

The initial value of the user.timezone system property is undefined unless set using a command line argument, for example, -Duser.timezone="America/New_York". The first time the default timezone is needed, if user.timezone is undefined or empty the timezone provided by the operating system is used. Previously, the initial value was the empty string. In JDK 12, System.getProperty("user.timezone") may return null.

Build 19

Add POSIX_SPAWN as an additional way to launch processes on Linux (JDK-8212828)

core-libs/java.lang

The property jdk.lang.Process.launchMechanism can be set to POSIX_SPAWN on Linux. This option has long been available on other *nix platforms. The default launch mechanism (VFORK) on Linux is unchanged, so this does not affect existing installations.

POSIX_SPAWN mitigates rare pathological cases when spawning child processes, but it has not yet been excessively tested, so prudence is advised in productive installations.

Build 18

TLS anon and NULL Cipher Suites are Disabled (JDK-8211883)

security-libs/javax.net.ssl

The TLS anon (anonymous) and NULL cipher suites have been added to the jdk.tls.disabledAlgorithms security property and are now disabled by default.

Removal finalize method in java.util.ZipFile/Inflator/Deflator (JDK-8212129)

core-libs/java.util.jar

Removal of the finalize method in java.util.ZipFile, java.util.Inflator, and java.util.Deflator in JDK 12:

The finalize method in java.util.ZipFile, java.util.Inflator, and java.util.Deflator was deprecated for removal in JDK 9 and its implementation was updated to be a no-op. Subclasses that override finalize in order to perform cleanup should be modified to use alternative cleanup mechanisms and to remove the overriding finalize method.

The removal of the finalize methods will expose Object.finalize to subclasses of ZipFile, Deflater, and Inflater. Compilation errors may occur on the override of finalize due to the change in declared exceptions. Object.finalize is declared to throw java.lang.Throwable; previously only java.io.IOException was declared.

G1 may uncommit memory during marking cycle (JDK-6490394)

hotspot/gc

By default, G1 may now give back Java heap memory to the operating system during any concurrent mark cycle. G1 will respect default Java heap sizing policies at that time.

This change improves memory usage of the Java process if the application does not need all memory.

This behavior may be disabled in accordance with default heap sizing policies by setting minimum Java heap size to maximum Java heap size via the -Xms option.

Build 17

Removal of GTE CyberTrust Global Root (JDK-8195793)

security-libs/java.security

The GTE CyberTrust Global Root certificate is expired and has been removed from the cacerts keystore:

  • alias name "gtecybertrustglobalca [jdk]"

    Distinguished Name: CN=GTE CyberTrust Global Root, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US

Build 16

New disallow and allow options for the java.security.manager system property (JDK-8191053)

security-libs/java.security

New "disallow" and "allow" token options have been added to the java.security.manager system property. In the JDK implementation, if the Java virtual machine is started with the system property java.security.manager set to "disallow" then the System.setSecurityManager method cannot be used to set a security manager and will throw an UnsupportedOperationException. The "disallow" option can improve run-time performance for applications that never set a security manager. For further details on the behavior of these options, see the class description of java.lang.SecurityManager.

Remove Finalize methods from FileInputStream and FileOutputStream (JDK-8192939)

core-libs/java.io

The finalize methods of FileInputStream and FileOutputStream have been removed; they were deprecated for removal in JDK 9. Thejava.lang.ref.Cleaner has been implemented since JDK 9 as the primary mechanism to close file descriptors that are no longer reachable from FileInputStream and FileOutputStream. The recommendation is to explicitly call close or use try-with-resources to close files.

Build 14

-XX:+/-MonitorInUseLists has been Obsoleted (JDK-8211384)

hotspot/runtime

The VM Option -XX:-MonitorInUseLists is obsolete in JDK 12 and ignored. Use of this flag will result in a warning being issued and may be removed completely in a future release.

LDAPS Communication Failure (JDK-8211107)

core-libs/javax.naming

Application code using LDAPS with a socket connect timeout that is <= 0 ( the default value ), may encounter an exception when establishing the connection.

The top most frames from Exception stack traces of applications encountering such issues might resemble the following:

    javax.naming.ServiceUnavailableException: <server:port>; socket closed
    at   com.sun.jndi.ldap.Connection.readReply(Unknown Source)  
    at   com.sun.jndi.ldap.LdapClient.ldapBind(Unknown Source)
    ...

Support dns_canonicalize_hostname in krb5.conf (JDK-8210821)

security-libs/org.ietf.jgss:krb5

The dns_canonicalize_hostname flag in the krb5.conf configuration file is now supported by the JDK Kerberos implementation. When set to "true", a short hostname in a service principal name will be canonicalized to a fully qualified domain name if available. Otherwise, no canonicalization is performed. The default value is "true". This is also the behavior before JDK 12.

Removal of com.sun.awt.SecurityWarning Class (JDK-8210692)

client-libs/java.awt

The com.sun.awt.SecurityWarning class was deprecated forRemoval=true in JDK 11 (JDK-8205588). This class was unused in the JDK and has been removed in this release.

Build 12

ChaCha20 and Poly1305 TLS Cipher Suites (JDK-8140466)

security-libs/javax.net.ssl

New TLS cipher suites using the ChaCha20-Poly1305 algorithm have been added to JSSE. These cipher suites are enabled by default. The TLS_CHACHA20_POLY1305_SHA256 cipher suite is available for TLS 1.3. The following cipher suites are available for TLS 1.2: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, and TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256.

Please refer to the "Java Secure Socket Extension (JSSE) Reference Guide" for more details on these new TLS cipher suites.

Build 11

Added Additional TeliaSonera Root Certificate (JDK-8210432)

security-libs/java.security

The following root certificate have been added to the OpenJDK cacerts truststore:

  • TeliaSonera
    • teliasonerarootcav1

      DN: CN=TeliaSonera Root CA v1, O=TeliaSonera

Build 8

Disabled All DES TLS Cipher Suites (JDK-8208350)

security-libs/javax.net.ssl

DES-based TLS cipher suites are considered obsolete and should no longer be used. DES-based cipher suites have been deactivated by default in the SunJSSE implementation by adding the "DES" identifier to the jdk.tls.disabledAlgorithms security property. These cipher suites can be reactivated by removing "DES" from the jdk.tls.disabledAlgorithms security property in the java.security file or by dynamically calling the Security.setProperty() method. In both cases re-enabling DES must be followed by adding DES-based cipher suites to the enabled cipher suite list using the SSLSocket.setEnabledCipherSuites() or SSLEngine.setEnabledCipherSuites() methods.

Note that prior to this change, DES40_CBC (but not all DES) suites were disabled via the jdk.tls.disabledAlgorithms security property.

Build 3

Removal of AOL and Swisscom Root Certificates (JDK-8203230)

security-libs/java.security

The following root certificates have been removed from the cacerts truststore:

  • AOL

    • aolrootca1

      DN: CN=America Online Root Certification Authority 1, O=America Online Inc., C=US

    • aolrootca2

      DN: CN=America Online Root Certification Authority 2, O=America Online Inc., C=US

  • Swisscom

    • swisscomrootca2

      DN: CN=Swisscom Root CA 2, OU=Digital Certificate Services, O=Swisscom, C=ch

Delivered

JEP 334: JVM Constants API (JDK-8203252)

core-libs/java.lang.invoke

JEP 334 introduces an API to model nominal descriptions of key class-file and run-time artifacts, in particular constants that are loadable from the constant pool. It does so by defining a family of value-based symbolic reference (JVMS 5.1) types, in the newly added package java.lang.invoke.constant, capable of describing each kind of loadable constant. A symbolic reference describes a loadable constant in purely nominal form, separate from class loading or accessibility context. Some classes can act as their own symbolic references (e.g., String); for linkable constants a family of symbolic reference types has been added (ClassDesc, MethodTypeDesc, MethodHandleDesc, and DynamicConstantDesc) that contain the nominal information to describe these constants.