The following sections are included in these Release Notes:
These notes describe important changes, enhancements, removed APIs and features, deprecated APIs and features, and other information about JDK 12 and Java SE 12. 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 12 ( JSR 386)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 12 ( JSR 386) specification provides links to:
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 12. The Kinds of Compatibilitypage on the OpenJDK wiki identifies three types of potential compatibility issues for Java programs used in these descriptions:
This section describes some of the enhancements in Java SE 12 and JDK 12. 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 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)Platform Specification, which documents the changes to the specification made between Java SE 11 and Java SE 12. 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 12.
➜Support for Unicode 11 The JDK 12 release includes support for Unicode 11.0.0. Following the release of JDK 11, which supported Unicode 10.0.0, Unicode 11.0.0 introduced the following new features that are now included in JDK 12:
684 new characters that include important additions for the following:
7 new scripts :
11 new blocks that include 7 blocks for the new scripts listed above and 4 blocks for the following existing scripts:
➜POSIX_SPAWN Option on Linux
As an additional way to launch processes on Linux, the
jdk.lang.Process.launchMechanism property can be set to
POSIX_SPAWN. This option has been available for a long time on other *nix platforms. The default launch mechanism (
VFORK) on Linux is unchanged, so this additional option does not affect existing installations.
POSIX_SPAWN mitigates rare pathological cases when spawning child processes, but it has not yet been excessively tested. Prudence is advised when using
POSIX_SPAWN in productive installations.
➜JEP 334 JVM Constants API
The new package
java.lang.invoke.constant introduces an API to model nominal descriptions of 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, 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 (
DynamicConstantDesc) that contain the nominal information to describe these constants.
➜Support for Compact Number Formatting
NumberFormat adds support for formatting a number in its compact form. 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 can be formatted as "1M", depending upon the style specified by
NumberFormat.Style. The compact number formats are defined by LDML's specification for Compact Number Formats
NumberFormatfor compact number formatting. For example:
NumberFormat fmt = NumberFormat.getCompactNumberInstance(Locale.US, NumberFormat.Style.SHORT); String result = fmt.format(1000);
The example above results in "1K".
➜Square Character Support for Japanese New Era
The code point, U+32FF, is reserved by the Unicode Consortium to represent the Japanese square character for the new era that begins from May, 2019. Relevant methods in the
Character class return the same properties as the existing Japanese era characters (e.g., U+337E for "Meizi"). For details about the code point, see http://blog.unicode.org/2018/09/new-japanese-era.html
➜ZGC Concurrent Class Unloading
The Z Garbage Collector now supports class unloading. By unloading unused classes, data structures related to these classes can be freed, lowering the overall footprint of the application. Class unloading in ZGC happens concurrently, without stopping the execution of Java application threads, and has thus zero impact on GC pause times. This feature is enabled by default, but can be disabled using the command line option
➜Allocation of Old Generation of Java Heap on Alternate Memory Devices This experimental feature in G1 and Parallel GC allows them to allocate the old generation of the Java heap on an alternative memory device such as NV-DIMM memory.
Operating systems today expose NV-DIMM memory devices through the file system. Examples are NTFS DAX mode and ext4 DAX mode. Memory-mapped files in these file systems bypass the file cache and provide a direct mapping of virtual memory to the physical memory on the device. The specification of a path to an NV-DIMM file system by using the flag
-XX:AllocateOldGenAt=<path> enables this feature. There is no additional flag to enable this feature.
When enabled, young generation objects are placed in DRAM only while old generation objects are always allocated in NV-DIMM. At any given point, the collector guarantees that the total memory committed in DRAM and NV-DIMM memory is always less than the size of the heap as specified by
The current implementation pre-allocates the full Java heap size in the NV-DIMM file system to avoid problems with dynamic generation sizing. Users need to make sure there is enough free space on the NV-DIMM file system.
When enabled, the VM also limits the maximum size of the young generation based on available DRAM, although it is recommended that users set the maximum size of the young generation explicitly.
For example, if the VM is run with
-Xmx756g on a system with 32GB DRAM and 1024GB NV-DIMM memory, the collector will limit the young generation size based on following calculation:
-Xmnis specified: the maximum young generation size is set to 80% of available memory (25.6GB).
-Xmnis specified: the maximum young generation size is capped at 80% of available memory (25.6GB) regardless of the amount specified.
-XX:MaxRAMto let the VM know how much DRAM is available for use. If specified, maximum young gen size is set to 80% of the value in MaxRAM.
Enabling logging with the logging option
gc+ergo=info will print the maximum young generation size at startup.
➜HotSpot Windows OS Detection Correctly Identifies Windows Server 2019
Prior to this fix, Windows Server 2019 was recognized as "Windows Server 2016", which produced incorrect values in the
os.name system property and the
➜Command-Line Flag -XX+ExtensiveErrorReports
The command-line flag
-XX:+ExtensiveErrorReports has been added to allow more extensive reporting of information related 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.
➜disallow and allow Options for java.security.manager System Property
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 starts 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
➜-groupname Option Added to keytool Key Pair Generation
-groupname option has been added to
keytool -genkeypair so that 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 by using the
secp384r1 curve. Because there might be multiple curves with the same size, using the
-groupname option is preferred over the
➜New Java Flight Recorder (JFR) Security Events Four new JFR events have been added to the security library area. These events are disabled by default and can be enabled via the JFR configuration files or via standard JFR options.
Security.setProperty(String key, String value)method calls
➜ 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
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:
Refer to the "Java Secure Socket Extension (JSSE) Reference Guide" for details on these new TLS cipher suites.
krb5.confconfiguration 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.
➜jdeps --print-module-deps Reports Transitive Dependences
--list-reduce-deps options have been enhanced as follows.
--no-recursiveoption can be used to request non-transitive dependence analysis.
--ignore-missing-depsoption 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-depsoption 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
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)Platform Specification, which documents changes to the specification made between Java SE 11 and Java SE 12. 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 12. See CSRs Approved for JDK 12 for the list of CSRs closed in JDK 12.
➜Removal of finalize Methods from FileInputStream and FileOutputStream
finalize methods of
FileOutputStream were deprecated for removal in JDK 9. They have been removed in this release. The
java.lang.ref.Cleaner has been implemented since JDK 9 as the primary mechanism to close file descriptors that are no longer reachable from
FileOutputStream. The recommended approach to close files is to explicitly call
close or to use
➜Removal of finalize Method in java.util.ZipFile/Inflator/Deflator
finalize method in
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.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
The removal of the finalize methods will expose
Object.finalize to subclasses of
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.
java.vendor.version. As of that release it was set, in JDK builds from Oracle, to
Mare the year and month, respectively, of the GA date of the release. This string is most apparent to end users in the output of the
java --versioncommand, and related commands. For example, with JDK 11:
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
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, support for the 6/1.6 argument value for javac's
--releaseflags has been removed.
Additional sources of information about the APIs, features, and options deprecated in Java SE 12 and JDK 12 include:
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 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 12for the list of CSRs closed in JDK 12.
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
-keyalg value for the
-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.
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.
➜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
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
The effect of the change is as follows:
Properties.storeToXML: No change.
Properties.loadFromXMLwill have no problem reading such files.
Properties.storeToXML: Any documents containing DTDs not in the format as specified in
Properties.loadFromXMLwill be rejected. This means the DTD shall be exactly as follows (as generated by the
<!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) ...
The file system location in Windows for the
usagetracker.properties file has been moved from
There is no change in the file path for Linux, Solaris, or macOS.
Epsilon GC may have violated the specification requirements by accepting the type-incompatible store into the array, instead of throwing the ArrayStoreException. This is now handled correctly, both in this release, and associated backports. Users are advised to upgrade as soon as possible.
➜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
➜can_pop_frame and can_force_early_return Capabilities are Disabled if JVMCI Compiler is Used
can_force_early_return capabilities are disabled if a JVMCI compiler (like Graal) is used. As a result the corresponding functionality (
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:
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:
DN: CN=America Online Root Certification Authority 1, O=America Online Inc., C=US
DN: CN=America Online Root Certification Authority 2, O=America Online Inc., C=US
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
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 pagefor 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).
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
|Distinguished Name||SHA-256 Fingerprint|
|CN=GeoTrust Global CA, O=GeoTrust Inc., C=US||
|CN=GeoTrust Primary Certification Authority, O=GeoTrust Inc., C=US||
|CN=GeoTrust Primary Certification Authority - G2, OU=(c) 2007 GeoTrust Inc. - For authorized use only, O=GeoTrust Inc., C=US||
|CN=GeoTrust Primary Certification Authority - G3, OU=(c) 2008 GeoTrust Inc. - For authorized use only, O=GeoTrust Inc., C=US||
|CN=GeoTrust Universal CA, O=GeoTrust Inc., C=US||
|CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US||
|CN=thawte Primary Root CA - G2, OU="(c) 2007 thawte, Inc. - For authorized use only", O="thawte, Inc.", C=US||
|CN=thawte Primary Root CA - G3, OU="(c) 2008 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US||
|EMAILADDRESSfirstname.lastname@example.org, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA||
|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||
|OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US||
|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||
|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||
|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||
|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||
|CN=VeriSign Universal Root Certification Authority, OU="(c) 2008 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US||
Subordinate Certificates to be distrusted after 2019-12-31
|Distinguished Name||SHA-256 Fingerprint|
|CN=Apple IST CA 2 - G1, OU=Certification Authority, O=Apple Inc., C=US||
|CN=Apple IST CA 8 - G1, OU=Certification Authority, O=Apple Inc., C=US||
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.
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:
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
.jarfiles). OpenJDK is offered only as compressed archive (
—releasefor 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.
-XX:+UnlockCommercialFeaturesflag is used. Oracle JDK no longer requires the flag and prints a warning but continues execution if used.
java -versionis different. Oracle JDK returns
javaand includes the Oracle-specific identifier. OpenJDK returns OpenJDK and does not include the Oracle-specific identifier.
\legal\java.desktop\freetype.mdis therefore different.