➜ Customizing PKCS12 keystore Generation
New system and security properties have been added to enable 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.

Also, support for the following SHA-2 based HmacPBE algorithms have been added to the SunJCE provider: HmacPBESHA224, HmacPBESHA256, HmacPBESHA384, HmacPBESHA512, HmacPBESHA512/224, HmacPBESHA512/256

➜ChaCha20 and Poly1305 TLS Cipher Suites
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
• TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256

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

➜Support for dns_canonicalize_hostname in krb5.conf
The dns_canonicalize_hostname flag

➜jdeps --print-module-deps Reports Transitive Dependences
jdeps --print-module-deps, --list-deps, and --list-reduce-deps options have been enhanced as follows.

1. By default, they perform transitive module dependence analysis on libraries on the class path and module path, both directly and indirectly, as required by the given input JAR files or classes. Previously, they only reported the modules required by the given input JAR files or classes. The --no-recursive option can be used to request non-transitive dependence analysis.
2. By default, they flag any missing dependency, i.e. not found from class path and module path, as an error. The --ignore-missing-deps option can be used to suppress missing dependence errors. Note that a custom image is created with the list of modules output by jdeps when using the --ignore-missing-deps option for a non-modular application. Such an application, running on the custom image, might fail at runtime when missing dependence errors are suppressed.

➜JEP 325 Switch Expressions (Preview)
The Java language enhances the switch statement so that it can be used as either a statement or an expression. Using switch as an expression often results in code that is more concise and readable. Both the statement and expression form can use either traditional case ... : labels (with fall through) or simplified case ... -> labels (no fall through). Also, both forms can switch on multiple constants in one case. These enhancements to switch are a preview language feature

Removed Features and Options

This section describes the APIs, features, and options that were removed in Java SE 12 and JDK 12. The APIs described here are those that are provided with the Oracle JDK. It includes a complete implementation of the Java SE 12 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 12 and JDK 12 is the Java SE 12 ( JSR 386)

➜Removal of com.sun.awt.SecurityWarning Class
The com.sun.awt.SecurityWarning class was deprecated as forRemoval=true in JDK 11 (JDK-8205588

➜Removal of finalize Methods from FileInputStream and FileOutputStream
The finalize methods of FileInputStream and FileOutputStream were deprecated for removal in JDK 9. They have been removed in this release. 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 recommended approach to close files is to explicitly call close or to use try-with-resources.

➜Removal of finalize Method in java.util.ZipFile/Inflator/Deflator
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. The finalize method in java.util.ZipFile, java.util.Inflator, and java.util.Deflator has been removed in this release. 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 might occur on the override of finalize due to the change in declared exceptions. Object.finalize is now declared to throw java.lang.Throwable. Previously, only java.io.IOException was declared.

➜Dropped the YY.M Vendor Version String from Oracle-Produced Builds
The vendor version string was introduced in JDK 9 by JEP 322

java 11 2018-09-25
Java(TM) SE Runtime Environment 18.9 (build 11+28)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode)

As of JDK 12, JDK builds from Oracle will no longer include a vendor version string. As a consequence the system property java.vendor.version now has the value null, and the output of java --version and related commands will no longer include a vendor version string. For example, the output of the JDK 12 java --version command will be of the form:

      java 12 2019-03-19
Java(TM) SE Runtime Environment (build 12+17)
Java HotSpot(TM) 64-Bit Server VM (build 12+17, mixed mode)

The relevant difference with respect to JDK 11 is the absence of 19.3 from the last two lines. Existing programs or scripts that expect the java.vendor.version property to have a non-null value, or that parse the output of java --version or related commands, may require adjustment in order to work properly with JDK 12.

➜Removal of GTE CyberTrust Global Root
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

➜Removal of javac Support for 6/1.6 source, target, and release Values
Consistent with the policy outlined in JEP 182: Policy for Retiring javac -source and -target Options

Deprecated Features and Options

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

• The deprecated API page (API specification)
  identifies all deprecated APIs including those deprecated in Java SE 12.
• The Java SE 12 ( JSR 386) specification
  documents changes to the specification made between Java SE 11 and Java SE 12 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 12. See CSRs Approved for JDK 12

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

➜Deprecated Default Keytool -keyalg Value
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.

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.

➜Disable the File Canonicalization Cache by Default
The file canonicalization cache has long-standing correctness issues; see JDK-7066948. For this reason, the cache is now disabled by default. It can be re-enabled by setting the sun.io.useCanonCaches system property. The cache was removed in JDK 21; see JDK-8309215.

➜GTK+ 3.20 and Later Unsupported by Swing
Due to incompatible changes in the GTK+ 3 library versions 3.20 and later, the Swing GTK Look and Feel does not render some UI components when using this library. Therefore Linux installations with versions of GTK+ 3.20 and above are not supported for use by the Swing GTK Look And Feel in this release. Affected applications on such configurations should specify the system property -Djdk.gtk.version=2.2 to request GTK2+ based rendering instead.

➜Initial Value of user.timezone System Property Changed
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.

➜Better HTTP Redirection Support
In this release, the behavior of methods that application code uses to set request properties in java.net.HttpURLConnection has changed. When a redirect occurs automatically from the original destination server to a resource on a different server, then all such properties are cleared for the redirect and any subsequent redirects. If these properties are required to be set on the redirected requests, then the redirect responses should be handled by the application by calling HttpURLConnection.setInstanceFollowRedirects(false) for the original request.

➜Changed URLPermission Behavior with Query or Fragments in URL String
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.

➜Support New Japanese Era in java.time.chrono.JapaneseEra
The JapaneseEra class and its of(int), valueOf(String), and values() methods are clarified to accommodate future Japanese era additions, such as how the singleton instances are defined, what the associated integer era values are, etc.

➜Changed Properties.loadFromXML to Comply with Specification
The implementation of the java.util.Properties.loadFromXML method has been 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"> 

➜LDAPS Communication Failure
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)
...

➜G1 May Uncommit Memory During Marking Cycle
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.

➜can_pop_frame and can_force_early_return Capabilities are Disabled if JVMCI Compiler is Used
The JVMTI can_pop_frame and can_force_early_return capabilities are disabled if a JVMCI compiler (like Graal) is used. As a result the corresponding functionality (PopFrame and ForceEarlyReturnXXX functions) is not available to JVMTI agents. This issue is being tracked by JDK-8218885

➜Linux Native Code Checks
Additional safeguards to protect against buffer overruns in native code have been enabled on Linux. If a buffer overrun is encountered, the system will write the message "stack smashing detected" and the program will exit. Issues of this type should be reported to your vendor.

➜Added Additional TeliaSonera Root Certificate
The following root certificate have been added to the OpenJDK cacerts truststore:

• TeliaSonera

  • teliasonerarootcav1

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

➜Removal of AOL and Swisscom Root Certificates
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

➜Change to X25519 and X448 Encoded Private Key Format
The encoded format of X25519 and X448 private keys has been 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 be replaced with newly-generated private keys.

➜Removed TLS v1 and v1.1 from SSLContext Required Algorithms
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.

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

➜Disabled All DES TLS Cipher Suites
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.

➜Distrust TLS Server Certificates Anchored by Symantec Root CAs
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 on or 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

An exception to this policy is that TLS Server certificates issued through two subordinate Certificate Authorities managed by Apple, and identified below, will continue to be trusted as long as they are issued on or before December 31, 2019.

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.caDistrustPolicies security property in the java.security configuration file.

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

Root Certificates distrusted after 2019-04-16

Subordinate Certificates to be distrusted after 2019-12-31

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.

➜Deprecated NSWindowStyleMaskTexturedBackground
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
• apple.awt.transparentTitleBar
• apple.awt.fullWindowContent

Differences Between Oracle JDK and Oracle's OpenJDK

Although we have stated the goal to have OpenJDK and Oracle JDK binaries be as close to each other as possible there remains, at least for JDK 12, several differences between the two options.

The current differences are:

• Oracle JDK offers "installers" (msi, rpm, deb, etc.) which not only place the JDK binaries in your system but also contain update rules and in some cases handle some common configurations like set common environmental variables (such as, JAVA_HOME in Windows) and establish file associations (such as, use java to launch .jar files). OpenJDK is offered only as compressed archive (tar.gz or .zip).
• javac —release for release values 9 and 10 behave differently. Oracle JDK binaries include APIs that were not added to OpenJDK binaries such as javafx, resource management, and (pre JDK 11 changes) JFR APIs.
• Usage Logging is only available in Oracle JDK.
• OpenJDK continues to throw an error and halt if the -XX:+UnlockCommercialFeatures flag is used. Oracle JDK no longer requires the flag and prints a warning but continues execution if used.
• Oracle JDK requires that third-party cryptographic providers be signed with a Java Cryptography Extension (JCE) Code Signing Certificate. OpenJDK continues allowing the use of unsigned third-party crypto providers.
• The output of java -version is different. Oracle JDK returns java and includes the Oracle-specific identifier. OpenJDK returns OpenJDK and does not include the Oracle-specific identifier.
• Oracle JDK is released under the OTN License
  . OpenJDK is released under GPLv2wCP
  . License files included with each will therefore be different.
• Oracle JDK distributes FreeType under the FreeType license and OpenJDK does so under GPLv2. The contents of \legal\java.desktop\freetype.md is therefore different.
• Oracle JDK has Java cup and steam icons and OpenJDK has Duke icons.
• Oracle JDK source code includes "ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms." Source code distributed with OpenJDK refers to the GPL license terms instead.