August 18, 2022
The full version string for this update release is 18.0.2.1+1 (where "+" means "build"). The version number is 18.0.2.1.
The security baselines are unchanged from the release of JDK 18.0.2.
JRE Family Version | JRE Security Baseline (Full Version String) |
---|---|
18 | 18.0.2+9 |
17 | 17.0.4+11 |
11 | 11.0.16+11 |
8 | 8u341-b10 |
7 | 7u351-b07 |
Oracle recommends that the JDK is updated with each Critical Patch Update. In order to determine if a release is the latest, the Security Baseline page can be used to determine which is the latest version for each release family.
Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 18.0.2.1) be used after the next critical patch update scheduled for October 18, 2022.
Oracle recommends that all JDK 18 users, even those that have already updated to 18.0.2, uptake the 18.0.2.1 patch release.
Fixes a regression in the C2 JIT compiler which caused the Java Runtime to crash unpredictably.
July 19, 2022
The full version string for this update release is 18.0.2+9 (where "+" means "build"). The version number is 18.0.2.
The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 18.0.2 are specified in the following table:
JRE Family Version | JRE Security Baseline (Full Version String) |
---|---|
18 | 18.0.2+9 |
17 | 17.0.4+11 |
11 | 11.0.16+11 |
8 | 8u341-b10 |
7 | 7u351-b07 |
Oracle recommends that the JDK is updated with each Critical Patch Update. In order to determine if a release is the latest, the Security Baseline page can be used to determine which is the latest version for each release family.
Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 18.0.2) be used after the next critical patch update scheduled for October 18, 2022.
The “jdk.security.auth.subject.useTL” system property and the alternate ThreadLocal
implementation of the Subject::current
and Subject::callAs
APIs have been removed. The default implementation of these APIs is still supported.
The java.net.InetAddress
class has been updated to strictly accept IPv4 address literals in decimal quad notation. The InetAddress
class methods are updated to throw an java.net.UnknownHostException
for invalid IPv4 address literals. To disable this check, the new "jdk.net.allowAmbiguousIPAddressLiterals" system property can be set to "true".
Previous JDK releases used an incorrect interpretation of the Linux cgroups parameter "cpu.shares". This might cause the JVM to use fewer CPUs than available, leading to an under utilization of CPU resources when the JVM is used inside a container.
Starting from this JDK release, by default, the JVM no longer considers "cpu.shares" when deciding the number of threads to be used by the various thread pools. The -XX:+UseContainerCpuShares
command-line option can be used to revert to the previous behavior. This option is deprecated and may be removed in a future JDK release.
Deserialization of serialized method references to Object methods, which was using an interface as the type on which the method is invoked, can now be deserialized again. Note the classfiles need to be recompiled to allow the deserialization.
The following table lists the bug fixes included in the JDK 18.0.2 release:
# | JBS | Component | Subcomponent | Summary |
---|---|---|---|---|
1 | JDK-8285686 | client-libs | 2d | Update FreeType to 2.12.0 |
2 | JDK-8283217 | client-libs | 2d | Leak FcObjectSet in getFontConfigLocations() in fontpath.c |
3 | JDK-8284023 | client-libs | java.awt | java.sun.awt.X11GraphicsDevice.getDoubleBufferVisuals() leaks XdbeScreenVisualInfo |
4 | JDK-8284033 | client-libs | java.awt | Leak XVisualInfo in getAllConfigs in awt_GraphicsEnv.c |
5 | JDK-8278065 | core-libs | java.io:serialization | Refactor subclassAudits to use ClassValue |
6 | JDK-8285517 | core-libs | java.lang | System.getenv() returns unexpected value if environment variable has non ASCII character |
7 | JDK-8281168 | core-libs | java.lang.invoke | Micro-optimize VarForm.getMemberName for interpreter |
8 | JDK-8282444 | core-libs | java.lang.module | Module finder incorrectly assumes default file system path-separator character |
9 | JDK-8287162 | core-libs | java.nio | (zipfs) Performance regression related to support for POSIX file permissions |
10 | JDK-8286594 | core-libs | java.nio | (zipfs) Mention paths with dot elements in ZipException and cleanups |
11 | JDK-8285515 | core-libs | java.nio | (dc) DatagramChannel.disconnect fails with "Invalid argument" on macOS 12.4 |
12 | JDK-8282929 | core-libs | java.text | Localized monetary symbols are not reflected in `toLocalizedPattern` return value |
13 | JDK-8281615 | core-svc | debugger | Deadlock caused by jdwp agent |
14 | JDK-8284094 | core-svc | debugger | Memory leak in invoker_completeInvokeRequest() |
15 | JDK-8279219 | hotspot | compiler | [REDO] C2 crash when allocating array of size too large |
16 | JDK-8284848 | hotspot | compiler | C2: Compiler blackhole arguments should be treated as globally escaping |
17 | JDK-8280799 | hotspot | compiler | С2: assert(false) failed: cyclic dependency prevents range check elimination |
18 | JDK-8283451 | hotspot | compiler | C2: assert(_base == Long) failed: Not a Long |
19 | JDK-8282592 | hotspot | compiler | C2: assert(false) failed: graph should be schedulable |
20 | JDK-8282590 | hotspot | compiler | C2: assert(addp->is_AddP() && addp->outcnt() > 0) failed: Don't process dead nodes |
21 | JDK-8282312 | hotspot | compiler | Minor corrections to evbroadcasti32x4 intrinsic on x86 |
22 | JDK-8282194 | hotspot | compiler | C1: Missing side effects of dynamic constant linkage |
23 | JDK-8281811 | hotspot | compiler | assert(_base == Tuple) failed: Not a Tuple after JDK-8280799 |
24 | JDK-8256368 | hotspot | compiler | Avoid repeated upcalls into Java to re-resolve MH/VH linkers/invokers |
25 | JDK-8283641 | hotspot | compiler | Large value for CompileThresholdScaling causes assert |
26 | JDK-8283408 | hotspot | compiler | Fix a C2 crash when filling arrays with unsafe |
27 | JDK-8280867 | hotspot | compiler | Cpuid1Ecx feature parsing is incorrect for AMD CPUs |
28 | JDK-8280600 | hotspot | compiler | C2: assert(!had_error) failed: bad dominance |
29 | JDK-8279668 | hotspot | compiler | x86: AVX2 versions of vpxor should be asserted |
30 | JDK-8275337 | hotspot | compiler | C1: assert(false) failed: live_in set of first block must be empty |
31 | JDK-8280901 | hotspot | compiler | MethodHandle::linkToNative stub is missing w/ -Xint |
32 | JDK-8282874 | hotspot | compiler | Bad performance on gather/scatter API caused by different IntSpecies of indexMap |
33 | JDK-8281266 | hotspot | compiler | [JVMCI] MetaUtil.toInternalName() doesn't handle hidden classes correctly |
34 | JDK-8279822 | hotspot | compiler | CI: Constant pool entries in error state are not supported |
35 | JDK-8282231 | hotspot | compiler | x86-32: runtime call to SharedRuntime::ldiv corrupts registers |
36 | JDK-8283555 | hotspot | gc | G1: Concurrent mark accesses uninitialized BOT of closed archive regions |
37 | JDK-8284532 | hotspot | jfr | Memory leak in BitSet::BitMapFragmentTable in JFR leak profiler |
38 | JDK-8284549 | hotspot | jfr | JFR: FieldTable leaks FieldInfoTable member |
39 | JDK-8280476 | hotspot | runtime | [macOS] : hotspot arm64 bug exposed by latest clang |
40 | JDK-8282295 | hotspot | runtime | SymbolPropertyEntry::set_method_type fails with assert |
41 | JDK-8283469 | hotspot | runtime | Don't use memset to initialize members in FileMapInfo and fix memory leak |
42 | JDK-8281274 | hotspot | runtime | deal with ActiveProcessorCount in os::Linux::print_container_info |
43 | JDK-8283379 | hotspot | runtime | Memory leak in FileHeaderHelper |
44 | JDK-8281181 | hotspot | runtime | Do not use CPU Shares to compute active processor count |
45 | JDK-8283022 | security-libs | javax.crypto | com/sun/crypto/provider/Cipher/AEAD/GCMBufferTest.java failing with -Xcomp after 8273297 |
46 | JDK-8274524 | security-libs | javax.net.ssl | SSLSocket.close() hangs if it is called during the ssl handshake |
47 | JDK-8286444 | tools | javac | javac errors after JDK-8251329 are not helpful enough to find root cause |
48 | JDK-8282080 | tools | javac | Lambda deserialization fails for Object method references on interfaces |
49 | JDK-8286855 | tools | javac | javac error on invalid jar should only print filename |
May 2, 2022
The full version string for this update release is 18.0.1.1+2 (where "+" means "build"). The version number is 18.0.1.1.
The security baselines are unchanged from the release of JDK 18.0.1.
JRE Family Version | JRE Security Baseline (Full Version String) |
---|---|
18 | 18.0.1+10 |
17 | 17.0.3+8 |
11 | 11.0.15+8 |
8 | 8u331-b09 |
7 | 7u341-b08 |
Oracle recommends that the JDK is updated with each Critical Patch Update. In order to determine if a release is the latest, the Security Baseline page can be used to determine which is the latest version for each release family.
Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 18.0.1.1) be used after the next critical patch update scheduled for July 19, 2022.
The Windows implementation of java.io.File
allows access to NTFS Alternate Data Streams (ADS) by default. Such streams have a structure like “filename:streamname”. A system property jdk.io.File.enableADS
has been added to control this behavior. To disable ADS support in java.io.File
, the system property [jdk.io](http://jdk.io).File.enableADS
should be set to false
(case ignored). Stricter path checking however prevents the use of special devices such as NUL:
This release is based on the previous CPU and does not contain any additional security fixes. The following issues have also been resolved:
BugId | Category | Subcategory | Summary |
---|---|---|---|
JDK-8284920 | xml | javax.xml.path | Incorrect Token type causes XPath expression to return incorrect results |
JDK-8284548 | xml | jaxp | Invalid XPath expression causes StringIndexOutOfBoundsException |
April 19, 2022
The full version string for this update release is 18.0.1+10 (where "+" means "build"). The version number is 18.0.1.
The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 18.0.1 are specified in the following table:
JRE Family Version | JRE Security Baseline (Full Version String) |
---|---|
18 | 18.0.1+10 |
17 | 17.0.3+8 |
11 | 11.0.15+8 |
8 | 8u331-b09 |
7 | 7u341-b08 |
Oracle recommends that the JDK is updated with each Critical Patch Update. In order to determine if a release is the latest, the Security Baseline page can be used to determine which is the latest version for each release family.
Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 18.0.1) be used after the next critical patch update scheduled for July 19, 2022.
Three processing limits have been added to the XML libraries. These are:
jdk.xml.xpathExprGrpLimit
Description: Limits the number of groups an XPath expression can contain.
Type: integer
Value: A positive integer. A value less than or equal to 0 indicates no limit. If the value is not an integer, a NumberFormatException
is thrown. Default 10.
jdk.xml.xpathExprOpLimit
Description: Limits the number of operators an XPath expression can contain.
Type: integer
Value: A positive integer. A value less than or equal to 0 indicates no limit. If the value is not an integer, a NumberFormatException
is thrown. Default 100.
jdk.xml.xpathTotalOpLimit
Description: Limits the total number of XPath operators in an XSL Stylesheet.
Type: integer
Value: A positive integer. A value less than or equal to 0 indicates no limit. If the value is not an integer, a NumberFormatException
is thrown. Default 10000.
Supported processors
jdk.xml.xpathExprGrpLimit
and jdk.xml.xpathExprOpLimit
are supported by the XPath processor.
All three limits are supported by the XSLT processor.
Setting properties
For the XSLT processor, the properties can be changed through the TransformerFactory
. For example,
TransformerFactory factory = TransformerFactory.newInstance();
factory.setAttribute("jdk.xml.xpathTotalOpLimit", "1000");
For both the XPath and XSLT processors, the properties can be set through the system property and jaxp.properties
configuration file located in the conf
directory of the Java installation. For example,
System.setProperty("jdk.xml.xpathExprGrpLimit", "20");
or in the jaxp.properties
file,
jdk.xml.xpathExprGrpLimit=20
There are two known issues:
On macOS, only certificates with proper trust settings in the user keychain will be exposed as trusted certificate entries in the KeychainStore type of keystore. Also, calling the KeyStore::setCertificateEntry
method or the keytool -importcert
command on a KeychainStore keystore now fails with a KeyStoreException
. Instead, call the macOS "security add-trusted-cert" command to add a trusted certificate into the user keychain.
The parsing of URLs in the LDAP, DNS, and RMI built-in JNDI providers has been made more strict. The strength of the parsing can be controlled by system properties:
-Dcom.sun.jndi.ldapURLParsing="legacy" | "compat" | "strict" (to control "ldap:" URLs)
-Dcom.sun.jndi.dnsURLParsing="legacy" | "compat" | "strict" (to control "dns:" URLs)
-Dcom.sun.jndi.rmiURLParsing="legacy" | "compat" | "strict" (to control "rmi:" URLs)
The default value is "compat" for all of the three providers.
In "compat" and "strict" mode, more validation is performed. As an example, in the URL authority component, the new parsing only accepts brackets around IPv6 literal addresses. Developers are encouraged to use java.net.URI
constructors or its factory method to build URLs rather than handcrafting URL strings.
If an illegal URL string is found, a java.lang.IllegalArgumentException
or a javax.naming.NamingException
(or a subclass of it) is raised.
This release also contains fixes for security vulnerabilities described in the Oracle Critical Patch Update. For a more complete list of the bug fixes included in this release, see the JDK 18.0.1 Bug Fixes page.
The Java Platform, Standard Edition 18 Development Kit (JDK 18) is a feature release of the Java SE platform. It contains new features and enhancements in many functional areas. The Release Notes below describe the important changes, enhancements, removed APIs and features, deprecated APIs and features, and other information about JDK 18 and Java SE 18. Links to other sources of information about JDK 18 are also provided below:
You should be aware of the content in the Java SE 18 ( JSR 393) specification as well as the items described in this page.
The descriptions on this Release Notes page also identify potential compatibility issues that you might encounter when migrating to JDK 18. The Kinds of Compatibility page on the OpenJDK wiki identifies the following three types of potential compatibility issues for Java programs that might be used in these release notes:
See CSRs Approved for JDK 18 for the list of CSRs closed in JDK 18 and the Compatibility & Specification Review (CSR) page on the OpenJDK wiki for general information about compatibility.
The full version string for this release is build 18+36 (where "+" means "build"). The version number is 18.
IANA Data 2021e
JDK 18 contains IANA time zone data version 2021e. For more information, refer to Timezone Data Versions in the JRE Software.
This section describes some of the enhancements in Java SE 18 and JDK 18. In some cases, the descriptions provide links to additional detailed information about an issue or a change. The APIs described here are provided with the Oracle JDK. It includes a complete implementation of the Java SE 18 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 18 and JDK 18 is the Java SE 18 ( JSR 393) Platform Specification, which documents the changes to the specification made between Java SE 17 and Java SE 18. 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 18.
NOTE: Release Notes for JEPs that added new features or enhancements in this release are grouped in the following categories of Core library improvements and updates, Tool improvements, and Previews and Incubators. Release Notes for JEPs that deprecated or removed APIs, features, and options are described in Deprecated Features and Options.
JEPs for Core library improvements and updates:
Starting with JDK 18, UTF-8 is the default charset for the Java SE APIs. APIs that depend on the default charset now behave consistently across all JDK implementations and independently of the user’s operating system, locale, and configuration. Specifically, java.nio.charset.Charset#defaultCharset()
now returns UTF-8
charset by default. The file.encoding
system property is now a part of the implementation specification, which may accept UTF-8
or COMPAT
. The latter is a new property value that instructs the runtime to behave as previous releases. This change is significant to users who call APIs that depend on the default charset. Users can determine whether they'd be affected or not, by specifying -Dfile.encoding=UTF-8
as the command line option with the existing Java runtime environment.
For further details, see JEP 400
jwebserver, a command-line tool to start a minimal static web server, has been introduced. The tool and the accompanying API are located in the com.sun.net.httpserver package of the jdk.httpserver module and are designed to be used for prototyping, ad-hoc coding, and testing, particularly in educational contexts.
For further details, see JEP 408.
JEP 416 reimplements core reflection with method handles. Code that depends upon highly implementation-specific and undocumented aspects of the existing implementation might be impacted. Issues that might arise include:
MagicAccessorImpl
) no longer works and must be updated.modifiers
field of Method
, Field
and Constructor
class to be different from the underlying member might cause a runtime error. Such code must be updated.To mitigate this compatibility risk, you can enable the old implementation as a workaround by using -Djdk.reflect.useDirectMethodHandle=false
. We will remove the old core reflection implementation in a future release. The -Djdk.reflect.useDirectMethodHandle=false
workaround will stop working at that point.
For further details, see JEP 416.
Introduce a service-provider interface (SPI) for host name and address resolution, so that java.net.InetAddress can make use of resolvers other than the platform's built-in resolver. This new SPI allows replacing the operating system's native resolver, which is typically configured to use a combination of a local hosts file and the Domain Name System (DNS).
For further details, see JEP 418.
JEPs for Tool improvements:
An @snippet tag for JavaDoc's Standard Doclet has been added, to simplify the inclusion of example source code in API documentation.
For further details, see JEP 413 and A Programmmer's Guide to Snippets.
JEPs for Previews and Incubators:
Introduce an API to express vector computations that reliably compile at runtime to optimal vector instructions on supported CPU architectures, thus achieving performance superior to equivalent scalar computations.
For further details, see JEP 417.
Introduce an API by which Java programs can interoperate with code and data outside of the Java runtime. By efficiently invoking foreign functions (i.e., code outside the JVM), and by safely accessing foreign memory (i.e., memory not managed by the JVM), the API enables Java programs to call native libraries and process native data without the brittleness and danger of JNI.
For further details, see JEP 419.
Enhance the Java programming language with pattern matching for switch expressions and statements, along with extensions to the language of patterns. Extending pattern matching to switch allows an expression to be tested against a number of patterns, each with a specific action, so that complex data-oriented queries can be expressed concisely and safely.
For further details, see JEP 420.
NOTE: The following Release Notes describe new features in this release that are not related to the JEPs described above:
The Z Garbage Collector now supports string deduplication (JEP 192 ).
The Serial Garbage Collector now supports string deduplication (JEP 192).
The Parallel Garbage Collector now supports string deduplication (JEP 192).
The javax.tools.JavaFileManager
has been extended with two new methods, getJavaFileForOutputForOriginatingFiles
and getFileForOutputForOriginatingFiles
, that are used to create new files with specified originating files. The Filer
uses these methods when creating new files (with Filer.createSourceFile
, Filer.createClassFile
, Filer.createResource
) in order to pass along the files containing the originating elements.
A new method Charset.forName()
that takes fallback
charset object has been introduced in java.nio.charset
package. The new method returns fallback
if charsetName
is illegal or the charset object is not available for the name. If fallback
is passed as null
the caller can check if the named charset was available without having to catch the exceptions thrown by the Charset.forName(name)
method.
A new system property, java.properties.date
, has been introduced to allow applications to control the default date comment written out by the java.util.Properties::store
methods. This system property is expected to be set while launching java
. Any non-empty value of this system property results in that value being used as a comment instead of the default date comment. In the absence of this system property or when the value is empty, the Properties::store
methods continue to write the default date comment. An additional change has also been made in the implementation of the Properties::store
methods to write out the key/value property pairs in a deterministic order. The implementation of these methods now uses the natural sort order of the property keys while writing them out. However, the implementation of these methods continues to use the iteration order when any sub-class of java.util.Properties
overrides the entrySet()
method to return a different Set
than that returned by super.entrySet()
.
The combination of the deterministic ordering of the properties that get written out with the new system property is particularly useful in environments where applications require the contents of the stored properties to be reproducible. In such cases, applications are expected to provide a fixed value of their choice to this system property.
For annotation processors, the Messager
interface now has methods printError
, printWarning
, and printNote
to directly report errors, warnings, and notes, respectively.
In the javax.lang.model
API, the Elements
utility interface has a new method, getOutermostTypeElement
, which returns the outermost class or interface syntactically enclosing an element.
The method Elements.getFileObjectOf(Element)
maps from an Element
to the file object used to create the element.
The SourceVersion
enum class has methods to map between SourceVersion
values and Runtime.Version
values. In turn, Runtime.Version
can be used to map from a string representation of a version to a Runtime.Version
object.
Compilation Replay has been improved to make it more stable and catch up with new JVM features. Enhancements include:
Compilation Replay is a JVM feature of debug builds that is mainly used to reproduce crashes in the C1 or C2 JIT compilers.
JDK-8272773 introduces the VM option -XX:GCCardSizeInBytes
used to set a size of the area that a card table entry covers (the "card size") that is different from the previous fixed value of 512 bytes. Permissible values are now 128, 256, and 512 bytes for all platforms, and 1024 bytes for 64 bit platforms only. The default value remains 512 bytes.
The card size impacts the amount of work to be done when searching for references into an area that is to be evacuated (for example, young generation) during garbage collection. Smaller card sizes give more precise information about the location of these references, often leading to less work during garbage collection. At the same time, however, smaller card sizes can lead to more memory usage in storing this information. The increase in memory usage might result in slower performance of maintenance work during the garbage collection.
The JDK-8275056 enhancement extends the maximum allowed heap region size from 32MB to 512MB for the G1 garbage collector. Default ergonomic heap region size selection is still limited to 32MB regions maximum. Heap region sizes beyond that must be selected manually by using the -XX:G1HeapRegionSize
command line option.
This can be used to mitigate both inner and outer fragmentation issues with large objects on large heaps.
On very large heaps, using a larger heap region size may also decrease internal region management overhead and increase performance due to larger local allocation buffers.
A new JDK Flight Recorder Event, jdk.FinalizerStatistics
, identifies classes at runtime that use finalizers. The event is enabled by default in the JDK (in the default.jfc
and profile.jfc
JFR configuration files). When enabled, JFR will emit a jdk.FinalizerStatistics
event for each instantiated class with a non-empty finalize() method. The event includes: the class that overrides finalize()
, that class's CodeSource
, the number of times the class's finalizer has run, and the number of objects still on the heap (not yet finalized). For information about using JFR, see the User Guide.
If finalization has been disabled with the --finalization=disabled
option, no jdk.FinalizerStatistics
events are emitted.
PKCS#11 v3.0 adds several new APIs that support new function entry points, as well as message-based encryption for AEAD ciphers, etc. For JDK 18, the SunPKCS11 provider has been updated to support some of the new PKCS#11 v3.0 APIs. To be more specific, if the "functionList" attribute in the provider configuration file is not set, the SunPKCS11 provider will first try to locate the new PKCS#11 v3.0 C_GetInterface() method before falling back to the C_GetFunctionList() method to load the function pointers of the native PKCS#11 library. If the loaded PKCS#11 library is v3.0, then the SunPKCS11 provider will cancel crypto operations by trying the new PKCS#11 v3.0 C_SessionCancel() method instead of finishing off remaining operations and discarding the results. Support for other new PKCS#11 v3.0 APIs will be added in later releases.
New methods javax.security.auth.Subject::current
and javax.security.auth.Subject::callAs
have been created as replacements for existing methods javax.security.auth.Subject::getSubject
and javax.security.auth.Subject::doAs
. The javax.security.auth.Subject::getSubject
and javax.security.auth.Subject::doAs
methods are deprecated for removal because they depend on Security Manager APIs deprecated in JEP 411.
A KeyStore::getAttributes
method has been added that returns the attributes of an entry without having to retrieve the entry first. This is especially useful for a private key entry that has attributes that are not protected but previously could only be retrieved with a password.
An OCSP response signed with the RSASSA-PSS algorithm is now supported.
A new -version
option has been added to the keytool
and jarsigner
commands. This option is used to print the program version of keytool
and jarsigner
.
The cacerts
keystore file is now a password-less PKCS #12 file. All certificates inside are not encrypted and there is no MacData for password integrity. Since the PKCS12 and JKS keystore types are interoperable, existing code that uses a JKS KeyStore
to load the cacerts
file with any password (including null) continue to behave as expected and can view or extract the certificates contained within the keystore.
Calling keyStore.store(outputStream, null)
on a PKCS12 KeyStore creates a password-less PKCS12 file. The certificates inside the file are not encrypted and the file contains no MacData. This file can then be loaded with any password (including null
) when calling keyStore.load(inputStream, password)
.
The SunPKCS11 provider has been enhanced to support the following crypto services and algorithms when the underlying PKCS11 library supports the corresponding PKCS#11 mechanisms:
AES/KW/NoPadding Cipher <=> CKM_AES_KEY_WRAP mechanism
AES/KW/PKCS5Padding Cipher <=> CKM_AES_KEY_WRAP_PAD mechanism
AES/KWP/NoPadding Cipher <=> CKM_AES_KEY_WRAP_KWP mechanism
The serial
lint warning implemented in javac
traditionally checked that a Serializable
class declared a serialVersionUID
field. The structural checking done by the serial
lint warning has been expanded to warn for cases where declarations would cause the runtime serialization mechanism to silently ignore a mis-declared entity, rendering it ineffectual. Also, the checks include several compile-time patterns that could lead to runtime failures. The specific checks include:
Serializable
classes and interfaces, fields and methods with names matching the special fields and methods used by the serialization mechanism are declared properly.Externalizable
types as some serialization-related methods are ineffectual there.readObject
, readObjectNoData
, or writeObject
method is defined, a warning is issued since a class implementing the interface will be unable to declare private
versions of those methods and the methods must be private
to be effective. If an interface defines default writeReplace
or readResolve
methods, a warning will be issued since serialization only looks up the superclass chain for those methods and not for default methods from interfaces. Since a serialPersistentFields
field must be private
to be effective, the presence of such a (non-private) field an in interface generates a warning.serialPersistentFields
, the type of each non-transient instance field is examined and a warning issued if the type of the field cannot be serialized. Primitive types, types declared to be serializable, and arrays can be serialized. While by the JLS all arrays are considered serializable, a warning is issued if the innermost component type is not serializable.The new warnings can be suppressed using @SuppressWarnings("serial")
.
The Standard Doclet supports an --add-script
option used to include a reference to an external script file in the file for each page of generated documentation.
You can now use @SuppressWarnings
annotations to suppress messages from DocLint about issues in documentation comments, when it is not possible or practical to fix the issues that were found. For more details, see Suppressing Messages in the DocLint section of the javadoc Tool Guide.
This section describes the APIs, features, and options that were removed in Java SE 18 and JDK 18. The APIs described here are those that are provided with the Oracle JDK. It includes a complete implementation of the Java SE 18 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 18 and JDK 18 is the Java SE 18 ( JSR 393) Platform Specification, which documents changes to the specification made between Java SE 17 and Java SE 18. 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 18. See CSRs Approved for JDK 18 for the list of CSRs closed in JDK 18.
The following root certificate from IdenTrust has been removed from the cacerts
keystore:
+ alias name "identrustdstx3 [jdk]"
Distinguished Name: CN=DST Root CA X3, O=Digital Signature Trust Co.
The following root certificate from Google has been removed from the cacerts
keystore:
+ alias name "globalsignr2ca [jdk]"
Distinguished Name: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2
The java.desktop
module had a few implementations of finalize()
that did nothing. These methods were deprecated in Java 9 and terminally deprecated in Java 16. These methods have been removed in this release. See https://bugs.openjdk.java.net/browse/JDK-8273103 for details.
Support for pre JDK 1.4 DatagramSocketImpl
implementations (DatagramSocketImpl implementations that don't support connected datagram sockets, peeking, or joining multicast groups on specific network interface) has been dropped in this release. Old implementations have not have been buildable since JDK 1.4 but implementations compiled with JDK 1.3 or older continued to be usable up to this release.
Trying to call connect
or disconnect
on a DatagramSocket
or MulticastSocket
that uses an old implementation will now throw SocketException
or UncheckedIOException
. Trying to call joinGroup
or leaveGroup
will result in an AbstractMethodError
.
The system property impl.prefix
has been removed. This undocumented system property dates from early JDK releases where it was possible to add an implementation of the JDK internal and non-public java.net.InetAddressImpl
interface to the java.net
package, and have it be used by the java.net.InetAddress
API.
The InetAddressResolver
SPI introduced by JEP 418 provides a standard way to implement a name and address resolver.
Legacy implementations of java.net.SocketImpl
and java.net.DatagramSocketImpl
have been removed from the JDK. The legacy implementation of SocketImpl
has not been used by default since JDK 13, while the legacy implementation of DatagramSocketImpl
has not been used by default since JDK 15. Support for system properties jdk.net.usePlainSocketImpl
and jdk.net.usePlainDatagramSocketImpl
used to select these implementations has also been removed. Setting these properties now has no effect.
The "default_checksum" and "safe_checksum_type" settings in the krb5.conf
configuration file are no longer supported. The checksum type in a KRB_TGS_REQ message is derived from the type of the encryption key used to generate it. The "safe_checksum_type" setting was never used in Java.
Additional sources of information about the APIs, features, and options deprecated in Java SE 18 and JDK 18 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
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 18. See CSRs Approved for JDK 18 for the list of CSRs closed in JDK 18.
NOTE: Release Notes for JEPs that deprecated or removed APIs, features, and options in this release are grouped in the following category:
JEPs for Deprecation and Removals:
The finalization mechanism has been deprecated for removal in a future release. The finalize
methods in standard Java APIs, such as Object.finalize()
and Enum.finalize()
, have also been deprecated for removal in a future release, along with methods related to finalization, such as Runtime.runFinalization()
and System.runFinalization()
.
Finalization remains enabled by default, but it can be disabled for testing purposes by using the command-line option --finalization=disabled
introduced in this release. Maintainers of libraries and applications that rely upon finalization should migrate to other resource management techniques in their code, such as try-with-resources and cleaners.
For further details, see JEP 421.
NOTE: The following Release Notes, not related to JEPs, describe deprecated or removed APIs, features, and options in this release:
Two javax.security.auth.Subject::doAs
methods have been deprecated for removal. This is a part of the ongoing effort to remove Security Manager related APIs.
Developers that use the unsupported sun.misc.Unsafe
API should be aware that the methods that return base and field offsets have been deprecated in this release. The methods objectFieldOffset
, staticFieldOffset
, and staticFieldBase
methods are an impediment to future changes. A future release will eventually degrade or remove these methods along with the heap accessor methods.
The java.lang.invoke.VarHandle
API (added in Java 9) provides a strongly typed reference to a variable that is safe and a replacement to many cases that use field offsets and the heap accessor methods. It is strongly recommended to migrate to the VarHandle
API where possible. Multi-Release JARs can be used by libraries and frameworks that continue to support JDK 8 or older.
Thread.stop
is terminally deprecated in this release so that it can be degraded in a future release and eventually removed. The method is inherently unsafe and has been deprecated since Java 1.2 (1998).
The options -XX:G1RSetRegionEntries
and -XX:G1RSetSparseRegionEntries
have been obsoleted with the changes from JDK-8017163.
JDK-8017163 implements a completely new remembered set implementation in which these two options no longer apply. In this release, neither -XX:G1RSetRegionEntries
nor -XX:G1RSetSparseRegionEntries
have a function, and their use will trigger an obsoletion warning.
The VM option UseBiasedLocking
along with the VM options BiasedLockingStartupDelay
, BiasedLockingBulkRebiasThreshold
, BiasedLockingBulkRevokeThreshold
, BiasedLockingDecayTime
and UseOptoBiasInlining
have been obsoleted. Use of these options will produce an obsolete option warning but will otherwise be ignored. Biased locking has been disabled by default and deprecated since JDK 15.
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.
On Windows 11 and Windows Server 2022, there can be some slowness with the extraction of temporary installation files when launched from a mapped network drive. The installer will still work, but there can be a temporary delay.
The default value of the java.security.manager
system property has been changed to disallow
. Unless the system property is set to allow
on the command line, any invocation of System.setSecurityManager(SecurityManager)
with a non-null argument will throw an UnsupportedOperationException
.
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.
To reduce the compatibility risk for applications that have been previously timestamped, there is one exception to this policy:
This exception might be removed in a future JDK release.
Users can, at their own risk, remove these restrictions by modifying the java.security
configuration file (or override it by using the java.security.properties
system property) and removing "SHA1 usage SignedJAR & denyAfter 2019-01-01" from the jdk.certpath.disabledAlgorithms
security property and "SHA1 denyAfter 2019-01-01" from the jdk.jar.disabledAlgorithms
security property.
Prior to JDK 18, when javac compiles an inner class it always generates a private synthetic field with a name starting with this$
to hold a reference to the enclosing instance, even if the inner class does not reference its enclosing instance and the field is unused.
Starting in JDK 18, unused this$
fields are omitted; the field is only generated for inner classes that reference their enclosing instance.
For example, consider the following program:
class T {
class I {
}
}
Prior to JDK 18, the program would be translated as:
class T {
class I {
private synthetic T this$0;
I(T this$0) {
this.this$0 = this$0;
}
}
}
Starting in JDK 18, the unused this$0
field is omitted:
class T {
class I {
I(T this$0) {}
}
}
Note that the form of the inner class constructor is not affected by this change.
The change may cause enclosing instances to be garbage collected sooner, if previously they were only reachable from a reference in an inner class. This is typically desirable, since it avoids a source of potential memory leaks when creating inner classes that are intended to outlive their enclosing instance.
Subclasses of java.io.Serializable
are not affected by this change.
For a reference to a specific overload of an overloaded method, the javadoc tool might have linked to the wrong overload in the generated documentation. This fix resolves that issue, and the specified overload will now be used for the links in the generated documentation.
The java.io.PrintStream
, PrintWriter
, and OutputStreamWriter
constructors that take a java.io.OutputStream
and no charset now inherit the charset when the output stream is a PrintStream
. This is important for usages such as:
new PrintWriter(System.out)
where it would be problematic if PrintStream
didn't use the same charset as that used by System.out
. This change was needed because JEP 400 makes it is possible, especially on Windows, that the encoding of System.out
is not UTF-8. This would cause problems if PrintStream
were wrapped with a PrintWriter
that used UTF-8.
As part of this change, java.io.PrintStream
now defines a charset()
method to return the print stream's charset.
The java.io.ObjectInputStream.GetField.get(String name, Object val)
method now throws ClassNotFoundException
when the class of the object is not found. Previously, null was returned, which prevented the caller from correctly handling the case where the class was not found. The signature of GetField.get(name, val)
has been updated to throw ClassNotFoundException
and a ClassNotFoundException
exception is thrown when the class is not found.
The source compatibility risk is low. The addition of a throws ClassNotFoundException
should not cause a source compatibility or a compilation warning. The GetField
object and its methods are called within the context of the readObject
method and include throws ClassNotFoundException
.
To revert to the old behavior, a system property, jdk.serialGetFieldCnfeReturnsNull
, has been added to the implementation. Setting the value to true
reverts to the old behavior (returning null); leaving it unset or to any other value results in the throwing of ClassNotFoundException
.
Invalid values of the command line and the security properties of jdk.serialFilter
and jdk.serialFilterFactory
are reported by throwing java.lang.IllegalStateException
on the first use. The property values are checked when constructing java.io.ObjectInputStream
or when calling the methods of java.io.ObjectInputFilter.Config
including getSerialFilter()
and getSerialFilterFactory()
. The IllegalStateException
indicates that the serial filter or serial filter factory is invalid and cannot be used; deserialization is disabled. Previously, the exception thrown was ExceptionInInitializerError
.
The scope of the com.sun.jndi.ldap.object.trustSerialData
system property has been extended to control the deserialization of java objects from the javaReferenceAddress
LDAP attribute. This system property now controls the deserialization of java objects from the javaSerializedData
and javaReferenceAddress
LDAP attributes.
To prevent deserialization of java objects from these attributes, the system property can be set to false
. By default, the deserialization of java objects from javaSerializedData
and javaReferenceAddress
attributes is allowed.
URLConnection
has been fixed to return multiple header values for a given field-name in the order in which they were added.
Previously, if a URLConnection
contained multiple header values for a given header field-name, when retrieved by using the HttpURLConnection::getHeaderFields
and the URLConnection::getRequestProperties
methods, they would be returned in the reverse order to which they were added.
This has been fixed to conform to RFC2616, which explicitly states that the order matters and thus, should be maintained.
In JDK 18, the handling of header names and values in jdk.httpserver/com.sun.net.httpserver.Headers
has been reconciled. This includes the eager and consistent prohibition of null
for names and values. The class represents header names and values as a key-value mapping of Map<String, List <String>>
. Previously, it was possible to create a headers instance with a null
key or value, which would cause undocumented exceptions when passed to the HttpServer
. It was also possible to query the instance for a null
key and false
would be returned. With this change, all methods of the class now throw a NullPointerException
if the key or value arguments are null
. For more information, see https://bugs.openjdk.java.net/browse/JDK-8269296.
ReadableByteChannel::read
no longer incorrectly throws ReadOnlyBufferException
.
The read(ByteBuffer)
method of the ReadableByteChannel
returned by java.nio.channels.Channel.newChannel(InputStream)
was incorrectly throwing ReadOnlyBufferException
when its ByteBuffer
parameter specified a read-only buffer. ReadableByteChannel::read
is, however, specified in this case to throw an IllegalArgumentException
. The implementation has been changed for this case to throw an IllegalArgumentException
instead of a ReadOnlyBufferException
, as dictated by the specification.
The ZIP file system provider has been changed to reject existing ZIP files that contain entries with "." or ".." in name elements. ZIP files with these entries cannot be used as a file system. Invoking the java.nio.file.FileSystems.newFileSystem(...)
methods throw ZipException
if the ZIP file contains these entries.
The IANA Time Zone Database, on which the JDK's Date/Time libraries are based, has made a tweak to some of the time zone rules in 2021c.
Note that in 2021b, which is cumulatively included in this change, some of the time zone rules prior to the year 1970 have been modified according to changes introduced with 2021b. For more details, refer to the announcement of 2021b.
JAR Index has been disabled in this release. JAR Index was an optimization to postpone downloading of JAR files when loading applets or other classes over the network. JAR Index has many long standing issues and does not interact well with newer features (such as, Multi-Release JARs and modular JARs). If a JAR file contains an INDEX.LIST file, then its contents are ignored by the application class loader and by any URLClassLoader created by user code.
The system property, jdk.net.URLClassPath.enableJarIndex
, can be used re-enable the feature if required. If set to an empty string or the value "true", then JAR Index will be re-enabled. This system property is temporary. A future release will remove the JAR Index feature and the system property.
The change does not impact the jar -i
option. The jar
tool continues to create an index when this option is used.
DeflaterOutputStream.close()
and GZIPOutputStream.finish()
has been changed to close out the associated default JDK compressor before propagating a Throwable up the stack. ZIPOutputStream.closeEntry()
has been changed to close out the associated default JDK compressor before propagating an IOException, not of type ZipException, up the stack.
A bug has been fixed that could cause long "Concurrent Process Non-Strong References" times with ZGC. The bug blocked the GC from making significant progress, and caused both latency and throughput issues for the Java application.
The long times could be seen in the GC logs when running with -Xlog:gc*
:
[17606.140s][info][gc,phases ] GC(719) Concurrent Process Non-Strong References 25781.928ms
The JDK implementation (as supplied by the SUN provider) of X509Certificate::getSubjectAlternativeNames
, X509Certificate::getIssuerAlternativeNames
and X509Certificate::getExtendedKeyUsage
now throws CertificateParsingException
instead of returning null
when the extension is non-critical and unparseable (badly encoded or contains invalid values). This change in behavior is compliant with the specification of these methods.
Support for AES/KW/NoPadding, AES/KW/PKCS5Padding and AES/KWP/NoPadding ciphers is added to SunJCE provider since jdk 17. The cipher block size for these transformations should be 8 instead of 16. In addition, for KWP mode, only the default IV, i.e. 0xA65959A6, is allowed to ensure maximum interoperability with other implementations. Other IV values will be rejected with exception during Cipher.init(...) calls.
The (D)TLS implementation in JDK now calls X509KeyManager.chooseClientAlias()
only once during handshaking for client authentication, even if there are multiple algorithms requested .
Weak encryption types based on DES, 3DES, and RC4 have been removed from the default encryption types list in Kerberos. These weak encryption types can be enabled (at your own risk) by adding them to the "permitted_enctypes" property (or alternatively, the "default_tkt_enctypes" or "default_tgt_enctypes" properties) and setting "allow_weak_crypto" to "true" in the krb5.conf
configuration file.
Various terms have been added to the index files in the JDK API documentation, so that these terms can be found in both the static A-Z index and in the interactive search index.
The terms are:
Language Model, Annotation Processing, Compiler API, and Compiler Tree API.
The pages generated by the Standard Doclet provide improved navigation controls when the pages are viewed on small devices.
DocLint detects and reports documentation comments that do not have a description about the associate declaration before any block tags that may be present. DocLint is a feature of the javac
and javadoc
tools that detects and reports issues in documentation comments.
The documentation in the Tool Guides ("man pages") for the javac
and javadoc
tools has been reorganized and updated. The primary documentation is now in the Tool Guide for javadoc
, with information about the tool-specific command-line options being given in the Options
section of the appropriate Tool Guide.
When the Standard Doclet encounters content in a documentation comment that it cannot process, it may create an element in the generated output to indicate clearly to the reader that the output at that position is not as the author intended. (This replaces the earlier behavior to show either nothing or the invalid content.) The element will contain a short summary message and may contain additional details. This is in addition to the existing behavior to report diagnostics and to return a suitable exit code.
The "Exceptions" and "Errors" tabs in documentation generated by JavaDoc have been merged into a single "Exception Classes" tab, which includes all exception classes, as defined in JLS 11.1.1.
The initialization of the file.encoding
system property on non macOS platforms has been reverted to align with the behavior on or before JDK 11. This has been an issue especially on Windows where the system and user's locales are not the same.
For JVMs running in a container, OperatingSystemMXBean.getProcessCpuLoad
now considers only the CPU resources available to the container when calculating CPU load. Prior to this change, the calculation included all CPUs on a host. After this change, management agents may report higher CPU usage by JVMs in containers that are constrained to a limited set of CPUs.
java.net.FileNameMap.getContentTypeFor(fileName)
May Return a Different MIME Type for Certain Filenames
The default, built-in filename map in the JDK has been updated to include additional filename to MIME type mappings. Along with the additions, existing mappings of .gz
and .zip
have also been updated. This can result in the default, built-in java.net.FileNameMap
instance returning a different MIME type from the getContentTypeFor(String fileName)
method than what it returned in previous JDK releases.
java.net.URLConnection.guessContentTypeFromName(String fname)
, which may use this default, built-in FileNameMap
instance, thus may return a different value than previously.