RELEASE NOTES FOR: 16 ==================================================================================================== Notes generated: Fri Jul 01 05:56:50 CEST 2022 Hint: Prefix bug IDs with https://bugs.openjdk.java.net/browse/ to reach the relevant JIRA entry. JAVA ENHANCEMENT PROPOSALS (JEP): JEP 338: Vector API (Incubator) Provide an initial iteration of an [incubator module](https://openjdk.java.net/jeps/11), `jdk.incubator.vector`, to express vector computations that reliably compile at runtime to optimal vector hardware instructions on supported CPU architectures and thus achieve superior performance to equivalent scalar computations. JEP 347: Enable C++14 Language Features Allow the use of C++14 language features in JDK C++ source code, and give specific guidance about which of those features may be used in HotSpot code. JEP 357: Migrate from Mercurial to Git Migrate the OpenJDK Community's source code repositories from Mercurial (hg) to Git. JEP 369: Migrate to GitHub Host the OpenJDK Community's Git repositories on [GitHub](https://www.github.com/). In concert with [JEP 357 (Migrate from Mercurial to Git)](https://openjdk.java.net/jeps/357), this would migrate all single-repository OpenJDK Projects to GitHub, including both [JDK feature releases](https://openjdk.java.net/projects/jdk/) and [JDK update releases](https://openjdk.java.net/projects/jdk-updates/) for versions 11 and later. JEP 376: ZGC: Concurrent Thread-Stack Processing Move ZGC thread-stack processing from safepoints to a concurrent phase. JEP 380: Unix-Domain Socket Channels Add Unix-domain (`AF_UNIX`) socket support to the [socket channel][socketchannel] and [server-socket channel][serversocketchannel] APIs in the `java.nio.channels` package. Extend the [inherited channel mechanism][inherited] to support Unix-domain socket channels and server socket channels. JEP 386: Alpine Linux Port Port the JDK to Alpine Linux, and to other Linux distributions that use musl as their primary C library, on both the x64 and AArch64 architectures, JEP 387: Elastic Metaspace Return unused HotSpot class-metadata (i.e., _metaspace_) memory to the operating system more promptly, reduce metaspace footprint, and simplify the metaspace code in order to reduce maintenance costs. JEP 388: Windows/AArch64 Port Port the JDK to Windows/AArch64. JEP 389: Foreign Linker API (Incubator) Introduce an API that offers statically-typed, pure-Java access to native code. This API, together with the Foreign-Memory API ([JEP 393][JEP-393]), will considerably simplify the otherwise error-prone process of binding to a native library. JEP 390: Warnings for Value-Based Classes Designate the primitive wrapper classes as _value-based_ and deprecate their constructors for removal, prompting new deprecation warnings. Provide warnings about improper attempts to synchronize on instances of any value-based classes in the Java Platform. JEP 392: Packaging Tool Provide the `jpackage` tool, for packaging self-contained Java applications. JEP 393: Foreign-Memory Access API (Third Incubator) Introduce an API to allow Java programs to safely and efficiently access foreign memory outside of the Java heap. JEP 394: Pattern Matching for instanceof Enhance the Java programming language with _pattern matching_ for the `instanceof` operator. [Pattern matching](https://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html) allows common logic in a program, namely the conditional extraction of components from objects, to be expressed more concisely and safely. JEP 395: Records Enhance the Java programming language with [records][records], which are classes that act as transparent carriers for immutable data. Records can be thought of as _nominal tuples_. JEP 396: Strongly Encapsulate JDK Internals by Default Strongly encapsulate all internal elements of the JDK by default, except for [critical internal APIs][crit] such as `sun.misc.Unsafe`. Allow end users to choose the relaxed strong encapsulation that has been the default since JDK 9. JEP 397: Sealed Classes (Second Preview) Enhance the Java programming language with [sealed classes and interfaces](https://cr.openjdk.java.net/~briangoetz/amber/datum.html). Sealed classes and interfaces restrict which other classes or interfaces may extend or implement them. This is a [preview language feature](http://openjdk.java.net/jeps/12) in JDK 16. RELEASE NOTES, BY COMPONENT: : JDK-8262495: JEP 390: Warnings for Value-based Classes Users of the _value-based classes_ provided by the standard libraries—notably including users of the primitive wrapper classes—should avoid relying on the identity of class instances. Programmers are strongly discouraged from calling the wrapper class constructors, which are now deprecated for removal. New `javac` warnings discourage synchronization on value-based class instances. Runtime warnings about synchronization can also be activated, using command-line option `-XX:DiagnoseSyncOnValueBasedClasses`. For further details, see [JEP 390](https://openjdk.java.net/jeps/390). tools/javac: JDK-8260623: Annotation Interfaces May Not Be Declared As Local Interfaces Prior to JDK 16, the `javac` compiler accepted annotations declared as local interfaces. Now the JLS 16 at section 14.3 forbids it. For example, the `javac` compiler had accepted code such as: ``` class C { void m() { @interface A {} } } ``` This code is no longer acceptable according to Section [14.3] of the JLS 16: "A local interface may be a normal interface (§9.1), but not an annotation interface (§9.6)." To fix this issue, the `javac` compiler implementation has been synchronized with the JLS 16, so that annotation interfaces cannot be declared as local interfaces. JDK-8261679: DocLint Support Moved to jdk.javadoc Module The code that provides the DocLint feature in _javac_ has been moved from the `jdk.compiler` module to the `jdk.javadoc` module. For most users, there will be no impact. However, any user wanting to build a minimal image for running _javac_ with DocLint enabled will need to ensure that the `jdk.javadoc` module is available when linking the image. JDK-8260739: C-Style Array Declarations Are Not Allowed in Record Components Prior to JDK 16, the `javac` compiler accepted C-style array declarations in record components. The JLS 16 now forbids it. In particular, the compiler had accepted code such as: ``` record R(int i[]) {} ``` This code is no longer acceptable according to the specification for JDK 16. Section 8.10.1 of the JLS 16 defines the syntax of a record component as: ``` RecordComponent: {RecordComponentModifier} UnannType Identifier VariableArityRecordComponent VariableArityRecordComponent: {RecordComponentModifier} UnannType { Annotation } ... Identifier RecordComponentModifier: Annotation ``` which clearly forbids C-style array declarations in record components. To fix this issue, the compiler has been synchronized with the JLS 16, so that C-style array declarations are no longer allowed in record components. JDK-8260623: Annotation Interfaces May Not Be Declared As Local Interfaces Prior to JDK 16, the `javac` compiler accepted annotations declared as local interfaces. Now the JLS 16 at section 14.3 forbids it. For example, the `javac` compiler had accepted code such as: ``` class C { void m() { @interface A {} } } ``` This code is no longer acceptable according to Section [14.3] of the JLS 16: "A local interface may be a normal interface (§9.1), but not an annotation interface (§9.6)." To fix this issue, the `javac` compiler implementation has been synchronized with the JLS 16, so that annotation interfaces cannot be declared as local interfaces. JDK-8261679: DocLint Support Moved to jdk.javadoc Module The code that provides the DocLint feature in _javac_ has been moved from the `jdk.compiler` module to the `jdk.javadoc` module. For most users, there will be no impact. However, any user wanting to build a minimal image for running _javac_ with DocLint enabled will need to ensure that the `jdk.javadoc` module is available when linking the image. JDK-8260739: C-Style Array Declarations Are Not Allowed in Record Components Prior to JDK 16, the `javac` compiler accepted C-style array declarations in record components. The JLS 16 now forbids it. In particular, the compiler had accepted code such as: ``` record R(int i[]) {} ``` This code is no longer acceptable according to the specification for JDK 16. Section 8.10.1 of the JLS 16 defines the syntax of a record component as: ``` RecordComponent: {RecordComponentModifier} UnannType Identifier VariableArityRecordComponent VariableArityRecordComponent: {RecordComponentModifier} UnannType { Annotation } ... Identifier RecordComponentModifier: Annotation ``` which clearly forbids C-style array declarations in record components. To fix this issue, the compiler has been synchronized with the JLS 16, so that C-style array declarations are no longer allowed in record components. JDK-8260623: Annotation Interfaces May Not Be Declared As Local Interfaces Prior to JDK 16, the `javac` compiler accepted annotations declared as local interfaces. Now the JLS 16 at section 14.3 forbids it. For example, the `javac` compiler had accepted code such as: ``` class C { void m() { @interface A {} } } ``` This code is no longer acceptable according to Section [14.3] of the JLS 16: "A local interface may be a normal interface (§9.1), but not an annotation interface (§9.6)." To fix this issue, the `javac` compiler implementation has been synchronized with the JLS 16, so that annotation interfaces cannot be declared as local interfaces. JDK-8261679: DocLint Support Moved to jdk.javadoc Module The code that provides the DocLint feature in _javac_ has been moved from the `jdk.compiler` module to the `jdk.javadoc` module. For most users, there will be no impact. However, any user wanting to build a minimal image for running _javac_ with DocLint enabled will need to ensure that the `jdk.javadoc` module is available when linking the image. JDK-8260739: C-Style Array Declarations Are Not Allowed in Record Components Prior to JDK 16, the `javac` compiler accepted C-style array declarations in record components. The JLS 16 now forbids it. In particular, the compiler had accepted code such as: ``` record R(int i[]) {} ``` This code is no longer acceptable according to the specification for JDK 16. Section 8.10.1 of the JLS 16 defines the syntax of a record component as: ``` RecordComponent: {RecordComponentModifier} UnannType Identifier VariableArityRecordComponent VariableArityRecordComponent: {RecordComponentModifier} UnannType { Annotation } ... Identifier RecordComponentModifier: Annotation ``` which clearly forbids C-style array declarations in record components. To fix this issue, the compiler has been synchronized with the JLS 16, so that C-style array declarations are no longer allowed in record components. core-libs/java.util: JDK-8256498: Argument Index of Zero or Unrepresentable by int Throws IllegalFormatException. Format string specifiers now throw exceptions when given values outside of valid ranges of values. The Formatter class in java.util defines format specifiers such as argument indexes, argument widths, and argument precisions. Numeric values that are invalid (zero for argument index) or too large (beyond the size of an int) could create unexpected results with undefined behavior. This update gives explicit value ranges for these format specifiers. Widths and indexes will be valid from [1, Integer.MAX_VALUE] and precision fields will be valid from [0, Integer.MAX_VALUE]. Values outside of these ranges will result in IllegalFormatException or one of its subclasses being thrown. Note that argument indexes of zero prior to this change did not throw an exception and produced behavior that was undefined, but had the appearance of correctness despite causing side effects that were not obvious. core-libs/java.net: JDK-8255764: `HttpPrincipal::getName` Returned Incorrect Name The behavior of the `HttpPrincipal::getName` method has been updated to return the name in the correct format as outlined in its specification, i.e. `"realm:username"`. Previously, the method incorrectly returned `"username"` only. JDK-8252515: The Default HttpClient Implementation Returns Cancelable Futures In this release, the default `HttpClient` returns *cancelable* futures. The default `HttpClient` is created by a call to `HttpClient.newHttpClient()`, or by invoking the `build` method on builders returned by `HttpClient.newBuilder()`. The implementation of the `sendAsync` methods in the default `HttpClient` now return `CompletableFuture` objects that are *cancelable*. Invoking `cancel(true)` on a *cancelable* future that is not completed, attempts to cancel the HTTP exchange in an effort to release underlying resources as soon as possible. More information can be obtained by reading the API documentation of the `HttpClient::sendAsync` methods. JDK-8251253: HttpClient.newHttpClient and HttpClient.Builder.build Might Throw UncheckedIOException Creation of an instance of `java.net.http.HttpClient` may fail with `UncheckedIOException` if the underlying resources required by the implementation cannot be allocated. Typically, this may happen if the underlying resources required to opening a `java.nio.channels.Selector` are not available. In this case `Selector.open()` will throw an `IOException` which the default implementation of `java.net.http.HttpClient` will wrap in an `UncheckedIOException`. The API documentation of `HttpClient.newHttpClient()` and `HttpClient.newBuilder().build()` have been updated to specify that `UncheckedIOException` may be thrown if the underlying resources required by the implementation cannot be allocated. Prior to this change, an undocumented `InternalError` would have been thrown. JDK-8255764: `HttpPrincipal::getName` Returned Incorrect Name The behavior of the `HttpPrincipal::getName` method has been updated to return the name in the correct format as outlined in its specification, i.e. `"realm:username"`. Previously, the method incorrectly returned `"username"` only. JDK-8252515: The Default HttpClient Implementation Returns Cancelable Futures In this release, the default `HttpClient` returns *cancelable* futures. The default `HttpClient` is created by a call to `HttpClient.newHttpClient()`, or by invoking the `build` method on builders returned by `HttpClient.newBuilder()`. The implementation of the `sendAsync` methods in the default `HttpClient` now return `CompletableFuture` objects that are *cancelable*. Invoking `cancel(true)` on a *cancelable* future that is not completed, attempts to cancel the HTTP exchange in an effort to release underlying resources as soon as possible. More information can be obtained by reading the API documentation of the `HttpClient::sendAsync` methods. JDK-8251253: HttpClient.newHttpClient and HttpClient.Builder.build Might Throw UncheckedIOException Creation of an instance of `java.net.http.HttpClient` may fail with `UncheckedIOException` if the underlying resources required by the implementation cannot be allocated. Typically, this may happen if the underlying resources required to opening a `java.nio.channels.Selector` are not available. In this case `Selector.open()` will throw an `IOException` which the default implementation of `java.net.http.HttpClient` will wrap in an `UncheckedIOException`. The API documentation of `HttpClient.newHttpClient()` and `HttpClient.newBuilder().build()` have been updated to specify that `UncheckedIOException` may be thrown if the underlying resources required by the implementation cannot be allocated. Prior to this change, an undocumented `InternalError` would have been thrown. JDK-8255764: `HttpPrincipal::getName` Returned Incorrect Name The behavior of the `HttpPrincipal::getName` method has been updated to return the name in the correct format as outlined in its specification, i.e. `"realm:username"`. Previously, the method incorrectly returned `"username"` only. JDK-8252515: The Default HttpClient Implementation Returns Cancelable Futures In this release, the default `HttpClient` returns *cancelable* futures. The default `HttpClient` is created by a call to `HttpClient.newHttpClient()`, or by invoking the `build` method on builders returned by `HttpClient.newBuilder()`. The implementation of the `sendAsync` methods in the default `HttpClient` now return `CompletableFuture` objects that are *cancelable*. Invoking `cancel(true)` on a *cancelable* future that is not completed, attempts to cancel the HTTP exchange in an effort to release underlying resources as soon as possible. More information can be obtained by reading the API documentation of the `HttpClient::sendAsync` methods. JDK-8251253: HttpClient.newHttpClient and HttpClient.Builder.build Might Throw UncheckedIOException Creation of an instance of `java.net.http.HttpClient` may fail with `UncheckedIOException` if the underlying resources required by the implementation cannot be allocated. Typically, this may happen if the underlying resources required to opening a `java.nio.channels.Selector` are not available. In this case `Selector.open()` will throw an `IOException` which the default implementation of `java.net.http.HttpClient` will wrap in an `UncheckedIOException`. The API documentation of `HttpClient.newHttpClient()` and `HttpClient.newBuilder().build()` have been updated to specify that `UncheckedIOException` may be thrown if the underlying resources required by the implementation cannot be allocated. Prior to this change, an undocumented `InternalError` would have been thrown. hotspot/jvmti: JDK-8256558: Make JVMTI Table Concurrent For improved performance, JVM/TI ObjectFree events are no longer posted within GC pauses. The events are still posted as requested, and will be posted before ObjectFree events are enabled or disabled with SetNotificationMode. SetNotificationMode can be used to explicitly flush ObjectFree events, if needed. core-libs/java.util:i18n: JDK-8255403: Support for CLDR Version 38 Locale data based on Unicode Consortium's CLDR has been upgraded to their version 38. For the detailed locale data changes, please refer to the Unicode Consortium's CLDR release notes: - [http://cldr.unicode.org/index/downloads/cldr-38](http://cldr.unicode.org/index/downloads/cldr-38) core-libs/java.lang: JDK-8249160: Support Supplementary Characters in String Case Insensitive Operations Case insensitive operations in `java.lang.String` class now correctly do case insensitive comparisons for supplementary characters (characters which have code point values over `U+FFFF`). For details, see the updates to the methods: ``` - compareToIgnoreCase(String other) - equalsIgnoreCase(String other) - regionMatches(boolean ignoreCase, ...) ``` For example, ``` "\ud801\udc00".equalsIgnoreCase("\ud801\udc28") ``` returns `true`, because '𐐀' ("\ud801\udc00") and '𐐨' ("\ud801\udc28") are equal to each other character in case insensitive comparison. JDK-8256652: Terminally Deprecated ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon The `stop`, `destroy`, `isDestroyed`, `setDaemon` and `isDaemon` methods defined by `java.lang.ThreadGroup` have been terminally deprecated in this release. `ThreadGroup::stop` is inherently unsafe and has been deprecated since Java 1.2. The method is now terminally deprecated and will be removed in a future release. The API and mechanism for destroying a ThreadGroup is inherently flawed. The methods that support explicitly or automatically destroying a thread group have been terminally deprecated and will be removed in a future release. JDK-8249160: Support Supplementary Characters in String Case Insensitive Operations Case insensitive operations in `java.lang.String` class now correctly do case insensitive comparisons for supplementary characters (characters which have code point values over `U+FFFF`). For details, see the updates to the methods: ``` - compareToIgnoreCase(String other) - equalsIgnoreCase(String other) - regionMatches(boolean ignoreCase, ...) ``` For example, ``` "\ud801\udc00".equalsIgnoreCase("\ud801\udc28") ``` returns `true`, because '𐐀' ("\ud801\udc00") and '𐐨' ("\ud801\udc28") are equal to each other character in case insensitive comparison. JDK-8256652: Terminally Deprecated ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon The `stop`, `destroy`, `isDestroyed`, `setDaemon` and `isDaemon` methods defined by `java.lang.ThreadGroup` have been terminally deprecated in this release. `ThreadGroup::stop` is inherently unsafe and has been deprecated since Java 1.2. The method is now terminally deprecated and will be removed in a future release. The API and mechanism for destroying a ThreadGroup is inherently flawed. The methods that support explicitly or automatically destroying a thread group have been terminally deprecated and will be removed in a future release. security-libs/javax.crypto:pkcs11: JDK-8257791: SunPKCS11 Provider Supports SHA-3 Related Algorithms The SunPKCS11 provider has been updated with SHA-3 algorithm support. Additional KeyGenerator support for Hmac using message digests other than SHA-3 has also been added. When the corresponding PKCS11 mechanisms are supported by the underlying PKCS11 library, the SunPKCS11 provider now supports the following additional algorithms: - MessageDigest: SHA3-224, SHA3-256, SHA3-384, SHA3-512 - Mac: HmacSHA3-224, HmacSHA3-256, HmacSHA3-384, HmacSHA3-512 - Signature: SHA3-224withDSA, SHA3-256withDSA, SHA3-384withDSA, SHA3-512withDSA, SHA3-224withDSAinP1363Format, SHA3-256withDSAinP1363Format, SHA3-384withDSAinP1363Format, SHA3-512withDSAinP1363Format, SHA3-224withECDSA, SHA3-256withECDSA, SHA3-384withECDSA, SHA3-512withECDSA, SHA3-224withECDSAinP1363Format, SHA3-256withECDSAinP1363Format, SHA3-384withECDSAinP1363Format, SHA3-512withECDSAinP1363Format, SHA3-224withRSA, SHA3-256withRSA, SHA3-384withRSA, SHA3-512withRSA, SHA3-224withRSASSA-PSS, SHA3-256withRSASSA-PSS, SHA3-384withRSASSA-PSS, SHA3-512withRSASSA-PSS. - KeyGenerator: HmacMD5, HmacSHA1, HmacSHA224, HmacSHA256, HmacSHA384, HmacSHA512, HmacSHA512/224, HmacSHA512/256, HmacSHA3-224, HmacSHA3-256, HmacSHA3-384, HmacSHA3-512. specification/language: JDK-8262150: JEP 397: Sealed Classes (Second Preview) Sealed classes and interfaces have been previewed again in JDK 16, initially added to the Java language in JDK 15. Sealed classes and interfaces restrict which other classes or interfaces may extend or implement them. For further details, see [JEP 397](https://openjdk.java.net/jeps/397). JDK-8262133: JEP 395: Records Records have been added to the Java language. Records are a new kind of class in the Java language. They act as transparent carriers for immutable data with less ceremony than normal classes. Since nested classes were first introduced to Java, with the exception of static final fields initialized by constant expressions, nested class declarations that are inner have been prohibited from declaring static members. This restriction applies to non-static member classes, local classes, and anonymous classes. [JEP 384: Records (Second Preview)](https://openjdk.java.net/jeps/384) added support for local interfaces, enum classes, and record classes, all of which are static definitions. This was a well-received enhancement, permitting coding styles that reduce the scope of certain declarations to local contexts. While [JEP 384](https://openjdk.java.net/jeps/384) allowed for static local classes and interfaces, it did not relax the restriction on static member classes and interfaces of inner classes. An inner class could declare a static interface inside one of its method bodies, but not as a class member. As a natural next step, [JEP 395](https://openjdk.java.net/jeps/395) further relaxes nesting restrictions, and permits static classes, methods, fields, etc., to be declared within inner classes. For further details, see [JEP 395](https://openjdk.java.net/jeps/395). JDK-8262138: JEP 394: Pattern Matching for instanceof Pattern matching for the `instanceof` operator has been made a final and permanent feature of the Java language in JDK 16. Pattern matching allows common logic in a Java program to be expressed more concisely and safely, namely the conditional extraction of components from objects. For further details, see [JEP 394](https://openjdk.java.net/jeps/394). JDK-8262150: JEP 397: Sealed Classes (Second Preview) Sealed classes and interfaces have been previewed again in JDK 16, initially added to the Java language in JDK 15. Sealed classes and interfaces restrict which other classes or interfaces may extend or implement them. For further details, see [JEP 397](https://openjdk.java.net/jeps/397). JDK-8262133: JEP 395: Records Records have been added to the Java language. Records are a new kind of class in the Java language. They act as transparent carriers for immutable data with less ceremony than normal classes. Since nested classes were first introduced to Java, with the exception of static final fields initialized by constant expressions, nested class declarations that are inner have been prohibited from declaring static members. This restriction applies to non-static member classes, local classes, and anonymous classes. [JEP 384: Records (Second Preview)](https://openjdk.java.net/jeps/384) added support for local interfaces, enum classes, and record classes, all of which are static definitions. This was a well-received enhancement, permitting coding styles that reduce the scope of certain declarations to local contexts. While [JEP 384](https://openjdk.java.net/jeps/384) allowed for static local classes and interfaces, it did not relax the restriction on static member classes and interfaces of inner classes. An inner class could declare a static interface inside one of its method bodies, but not as a class member. As a natural next step, [JEP 395](https://openjdk.java.net/jeps/395) further relaxes nesting restrictions, and permits static classes, methods, fields, etc., to be declared within inner classes. For further details, see [JEP 395](https://openjdk.java.net/jeps/395). JDK-8262138: JEP 394: Pattern Matching for instanceof Pattern matching for the `instanceof` operator has been made a final and permanent feature of the Java language in JDK 16. Pattern matching allows common logic in a Java program to be expressed more concisely and safely, namely the conditional extraction of components from objects. For further details, see [JEP 394](https://openjdk.java.net/jeps/394). JDK-8262150: JEP 397: Sealed Classes (Second Preview) Sealed classes and interfaces have been previewed again in JDK 16, initially added to the Java language in JDK 15. Sealed classes and interfaces restrict which other classes or interfaces may extend or implement them. For further details, see [JEP 397](https://openjdk.java.net/jeps/397). JDK-8262133: JEP 395: Records Records have been added to the Java language. Records are a new kind of class in the Java language. They act as transparent carriers for immutable data with less ceremony than normal classes. Since nested classes were first introduced to Java, with the exception of static final fields initialized by constant expressions, nested class declarations that are inner have been prohibited from declaring static members. This restriction applies to non-static member classes, local classes, and anonymous classes. [JEP 384: Records (Second Preview)](https://openjdk.java.net/jeps/384) added support for local interfaces, enum classes, and record classes, all of which are static definitions. This was a well-received enhancement, permitting coding styles that reduce the scope of certain declarations to local contexts. While [JEP 384](https://openjdk.java.net/jeps/384) allowed for static local classes and interfaces, it did not relax the restriction on static member classes and interfaces of inner classes. An inner class could declare a static interface inside one of its method bodies, but not as a class member. As a natural next step, [JEP 395](https://openjdk.java.net/jeps/395) further relaxes nesting restrictions, and permits static classes, methods, fields, etc., to be declared within inner classes. For further details, see [JEP 395](https://openjdk.java.net/jeps/395). JDK-8262138: JEP 394: Pattern Matching for instanceof Pattern matching for the `instanceof` operator has been made a final and permanent feature of the Java language in JDK 16. Pattern matching allows common logic in a Java program to be expressed more concisely and safely, namely the conditional extraction of components from objects. For further details, see [JEP 394](https://openjdk.java.net/jeps/394). hotspot/runtime: JDK-8260562: JEP 387: Elastic Metaspace [JEP 387](https://openjdk.java.net/jeps/387) "Elastic Metaspace" overhauls the VM-internal metaspace- and class-space-implementation. Less memory is used for class metadata. The savings effect is mostly noticeable in scenarios involving lots of small grained class loaders. Upon class unloading, memory is timely returned to the operating system. A switch is added to fine-tune metaspace reclamation: `-XX:MetaspaceReclaimPolicy=(balanced|aggressive|none)`. `balanced`, the default, causes the VM to reclaim memory while keeping computational overhead minimal; `aggressive` moderately increases the reclaim rate at the cost of somewhat more expensive bookkeeping; `none` switches reclamation off altogether. The switches `InitialBootClassLoaderMetaspaceSize` and `UseLargePagesInMetaspace` have been deprecated. JDK-8257795: Parts of the Signal-Chaining API Are Deprecated The signal-chaining facility was introduced in JDK 1.4 and supported three different Linux signal-handling API's: `sigset`, `signal` and `sigaction`. Only `sigaction` is a cross-platform, supported, API for multi-threaded processes. Both `signal` and `sigset` are considered obsolete on those platforms that still define them. Consequently, the use of `signal` and `sigset` with the signal-chaining facility are now deprecated, and support for their use will be removed in a future release. JDK-8260452: IncompatibleClassChangeError Exceptions Are Thrown For Failing 'final' Checks When Defining a Class As a result of changes to section 5.3.5 of the Java Virtual Machine Specification, a `java.lang.IncompatibleClassChangeError` exception is thrown instead of a `java.lang.VerifyError` exception when defining a class whose super class is final and when defining a class that tries to override a final method. JDK-8253225: Object Monitors No Longer Keep Strong References to Their Associated Object When synchronization is performed on an object, an association is established between the object and the object monitor that implements the synchronization. In the past, the reference from a monitor to its associated object was a strong reference. These strong references would be observable through JVM TI functions that walk the heap (reported as `JVMTI_HEAP_ROOT_MONITOR` or `JVMTI_HEAP_REFERENCE_MONITOR`) and in heap dumps (reported as `HPROF_GC_ROOT_MONITOR_USED`). As of this release, a weak reference is used. These are not observable to JVM TI or heap dumps. Consequently, `JVMTI_HEAP_ROOT_MONITOR`, `JVMTI_HEAP_REFERENCE_MONITOR` and `HPROF_GC_ROOT_MONITOR_USED` are longer reported. JDK-8257429: Deprecated Tracing Flags Are Obsolete and Must Be Replaced With Unified Logging Equivalents When Unified Logging was added in Java 9, a number of tracing flags were deprecated and mapped to their unified logging equivalent. These flags are now obsolete and will no longer be converted automatically to enable unified logging. To continue getting the same logging output, you must explicitly replace the use of these flags with their unified logging equivalent. | Obsoleted Option | Unified Logging Replacement | | ------------------------ | --------------------------- | | -XX:+TraceClassLoading | -Xlog:class+load=info | | -XX:+TraceClassUnloading | -Xlog:class+unload=info | | -XX:+TraceExceptions | -Xlog:exceptions=info | JDK-8260562: JEP 387: Elastic Metaspace [JEP 387](https://openjdk.java.net/jeps/387) "Elastic Metaspace" overhauls the VM-internal metaspace- and class-space-implementation. Less memory is used for class metadata. The savings effect is mostly noticeable in scenarios involving lots of small grained class loaders. Upon class unloading, memory is timely returned to the operating system. A switch is added to fine-tune metaspace reclamation: `-XX:MetaspaceReclaimPolicy=(balanced|aggressive|none)`. `balanced`, the default, causes the VM to reclaim memory while keeping computational overhead minimal; `aggressive` moderately increases the reclaim rate at the cost of somewhat more expensive bookkeeping; `none` switches reclamation off altogether. The switches `InitialBootClassLoaderMetaspaceSize` and `UseLargePagesInMetaspace` have been deprecated. JDK-8257795: Parts of the Signal-Chaining API Are Deprecated The signal-chaining facility was introduced in JDK 1.4 and supported three different Linux signal-handling API's: `sigset`, `signal` and `sigaction`. Only `sigaction` is a cross-platform, supported, API for multi-threaded processes. Both `signal` and `sigset` are considered obsolete on those platforms that still define them. Consequently, the use of `signal` and `sigset` with the signal-chaining facility are now deprecated, and support for their use will be removed in a future release. JDK-8260452: IncompatibleClassChangeError Exceptions Are Thrown For Failing 'final' Checks When Defining a Class As a result of changes to section 5.3.5 of the Java Virtual Machine Specification, a `java.lang.IncompatibleClassChangeError` exception is thrown instead of a `java.lang.VerifyError` exception when defining a class whose super class is final and when defining a class that tries to override a final method. JDK-8253225: Object Monitors No Longer Keep Strong References to Their Associated Object When synchronization is performed on an object, an association is established between the object and the object monitor that implements the synchronization. In the past, the reference from a monitor to its associated object was a strong reference. These strong references would be observable through JVM TI functions that walk the heap (reported as `JVMTI_HEAP_ROOT_MONITOR` or `JVMTI_HEAP_REFERENCE_MONITOR`) and in heap dumps (reported as `HPROF_GC_ROOT_MONITOR_USED`). As of this release, a weak reference is used. These are not observable to JVM TI or heap dumps. Consequently, `JVMTI_HEAP_ROOT_MONITOR`, `JVMTI_HEAP_REFERENCE_MONITOR` and `HPROF_GC_ROOT_MONITOR_USED` are longer reported. JDK-8257429: Deprecated Tracing Flags Are Obsolete and Must Be Replaced With Unified Logging Equivalents When Unified Logging was added in Java 9, a number of tracing flags were deprecated and mapped to their unified logging equivalent. These flags are now obsolete and will no longer be converted automatically to enable unified logging. To continue getting the same logging output, you must explicitly replace the use of these flags with their unified logging equivalent. | Obsoleted Option | Unified Logging Replacement | | ------------------------ | --------------------------- | | -XX:+TraceClassLoading | -Xlog:class+load=info | | -XX:+TraceClassUnloading | -Xlog:class+unload=info | | -XX:+TraceExceptions | -Xlog:exceptions=info | JDK-8260562: JEP 387: Elastic Metaspace [JEP 387](https://openjdk.java.net/jeps/387) "Elastic Metaspace" overhauls the VM-internal metaspace- and class-space-implementation. Less memory is used for class metadata. The savings effect is mostly noticeable in scenarios involving lots of small grained class loaders. Upon class unloading, memory is timely returned to the operating system. A switch is added to fine-tune metaspace reclamation: `-XX:MetaspaceReclaimPolicy=(balanced|aggressive|none)`. `balanced`, the default, causes the VM to reclaim memory while keeping computational overhead minimal; `aggressive` moderately increases the reclaim rate at the cost of somewhat more expensive bookkeeping; `none` switches reclamation off altogether. The switches `InitialBootClassLoaderMetaspaceSize` and `UseLargePagesInMetaspace` have been deprecated. JDK-8257795: Parts of the Signal-Chaining API Are Deprecated The signal-chaining facility was introduced in JDK 1.4 and supported three different Linux signal-handling API's: `sigset`, `signal` and `sigaction`. Only `sigaction` is a cross-platform, supported, API for multi-threaded processes. Both `signal` and `sigset` are considered obsolete on those platforms that still define them. Consequently, the use of `signal` and `sigset` with the signal-chaining facility are now deprecated, and support for their use will be removed in a future release. JDK-8260452: IncompatibleClassChangeError Exceptions Are Thrown For Failing 'final' Checks When Defining a Class As a result of changes to section 5.3.5 of the Java Virtual Machine Specification, a `java.lang.IncompatibleClassChangeError` exception is thrown instead of a `java.lang.VerifyError` exception when defining a class whose super class is final and when defining a class that tries to override a final method. JDK-8253225: Object Monitors No Longer Keep Strong References to Their Associated Object When synchronization is performed on an object, an association is established between the object and the object monitor that implements the synchronization. In the past, the reference from a monitor to its associated object was a strong reference. These strong references would be observable through JVM TI functions that walk the heap (reported as `JVMTI_HEAP_ROOT_MONITOR` or `JVMTI_HEAP_REFERENCE_MONITOR`) and in heap dumps (reported as `HPROF_GC_ROOT_MONITOR_USED`). As of this release, a weak reference is used. These are not observable to JVM TI or heap dumps. Consequently, `JVMTI_HEAP_ROOT_MONITOR`, `JVMTI_HEAP_REFERENCE_MONITOR` and `HPROF_GC_ROOT_MONITOR_USED` are longer reported. JDK-8257429: Deprecated Tracing Flags Are Obsolete and Must Be Replaced With Unified Logging Equivalents When Unified Logging was added in Java 9, a number of tracing flags were deprecated and mapped to their unified logging equivalent. These flags are now obsolete and will no longer be converted automatically to enable unified logging. To continue getting the same logging output, you must explicitly replace the use of these flags with their unified logging equivalent. | Obsoleted Option | Unified Logging Replacement | | ------------------------ | --------------------------- | | -XX:+TraceClassLoading | -Xlog:class+load=info | | -XX:+TraceClassUnloading | -Xlog:class+unload=info | | -XX:+TraceExceptions | -Xlog:exceptions=info | JDK-8260562: JEP 387: Elastic Metaspace [JEP 387](https://openjdk.java.net/jeps/387) "Elastic Metaspace" overhauls the VM-internal metaspace- and class-space-implementation. Less memory is used for class metadata. The savings effect is mostly noticeable in scenarios involving lots of small grained class loaders. Upon class unloading, memory is timely returned to the operating system. A switch is added to fine-tune metaspace reclamation: `-XX:MetaspaceReclaimPolicy=(balanced|aggressive|none)`. `balanced`, the default, causes the VM to reclaim memory while keeping computational overhead minimal; `aggressive` moderately increases the reclaim rate at the cost of somewhat more expensive bookkeeping; `none` switches reclamation off altogether. The switches `InitialBootClassLoaderMetaspaceSize` and `UseLargePagesInMetaspace` have been deprecated. JDK-8257795: Parts of the Signal-Chaining API Are Deprecated The signal-chaining facility was introduced in JDK 1.4 and supported three different Linux signal-handling API's: `sigset`, `signal` and `sigaction`. Only `sigaction` is a cross-platform, supported, API for multi-threaded processes. Both `signal` and `sigset` are considered obsolete on those platforms that still define them. Consequently, the use of `signal` and `sigset` with the signal-chaining facility are now deprecated, and support for their use will be removed in a future release. JDK-8260452: IncompatibleClassChangeError Exceptions Are Thrown For Failing 'final' Checks When Defining a Class As a result of changes to section 5.3.5 of the Java Virtual Machine Specification, a `java.lang.IncompatibleClassChangeError` exception is thrown instead of a `java.lang.VerifyError` exception when defining a class whose super class is final and when defining a class that tries to override a final method. JDK-8253225: Object Monitors No Longer Keep Strong References to Their Associated Object When synchronization is performed on an object, an association is established between the object and the object monitor that implements the synchronization. In the past, the reference from a monitor to its associated object was a strong reference. These strong references would be observable through JVM TI functions that walk the heap (reported as `JVMTI_HEAP_ROOT_MONITOR` or `JVMTI_HEAP_REFERENCE_MONITOR`) and in heap dumps (reported as `HPROF_GC_ROOT_MONITOR_USED`). As of this release, a weak reference is used. These are not observable to JVM TI or heap dumps. Consequently, `JVMTI_HEAP_ROOT_MONITOR`, `JVMTI_HEAP_REFERENCE_MONITOR` and `HPROF_GC_ROOT_MONITOR_USED` are longer reported. JDK-8257429: Deprecated Tracing Flags Are Obsolete and Must Be Replaced With Unified Logging Equivalents When Unified Logging was added in Java 9, a number of tracing flags were deprecated and mapped to their unified logging equivalent. These flags are now obsolete and will no longer be converted automatically to enable unified logging. To continue getting the same logging output, you must explicitly replace the use of these flags with their unified logging equivalent. | Obsoleted Option | Unified Logging Replacement | | ------------------------ | --------------------------- | | -XX:+TraceClassLoading | -Xlog:class+load=info | | -XX:+TraceClassUnloading | -Xlog:class+unload=info | | -XX:+TraceExceptions | -Xlog:exceptions=info | JDK-8260562: JEP 387: Elastic Metaspace [JEP 387](https://openjdk.java.net/jeps/387) "Elastic Metaspace" overhauls the VM-internal metaspace- and class-space-implementation. Less memory is used for class metadata. The savings effect is mostly noticeable in scenarios involving lots of small grained class loaders. Upon class unloading, memory is timely returned to the operating system. A switch is added to fine-tune metaspace reclamation: `-XX:MetaspaceReclaimPolicy=(balanced|aggressive|none)`. `balanced`, the default, causes the VM to reclaim memory while keeping computational overhead minimal; `aggressive` moderately increases the reclaim rate at the cost of somewhat more expensive bookkeeping; `none` switches reclamation off altogether. The switches `InitialBootClassLoaderMetaspaceSize` and `UseLargePagesInMetaspace` have been deprecated. JDK-8257795: Parts of the Signal-Chaining API Are Deprecated The signal-chaining facility was introduced in JDK 1.4 and supported three different Linux signal-handling API's: `sigset`, `signal` and `sigaction`. Only `sigaction` is a cross-platform, supported, API for multi-threaded processes. Both `signal` and `sigset` are considered obsolete on those platforms that still define them. Consequently, the use of `signal` and `sigset` with the signal-chaining facility are now deprecated, and support for their use will be removed in a future release. JDK-8260452: IncompatibleClassChangeError Exceptions Are Thrown For Failing 'final' Checks When Defining a Class As a result of changes to section 5.3.5 of the Java Virtual Machine Specification, a `java.lang.IncompatibleClassChangeError` exception is thrown instead of a `java.lang.VerifyError` exception when defining a class whose super class is final and when defining a class that tries to override a final method. JDK-8253225: Object Monitors No Longer Keep Strong References to Their Associated Object When synchronization is performed on an object, an association is established between the object and the object monitor that implements the synchronization. In the past, the reference from a monitor to its associated object was a strong reference. These strong references would be observable through JVM TI functions that walk the heap (reported as `JVMTI_HEAP_ROOT_MONITOR` or `JVMTI_HEAP_REFERENCE_MONITOR`) and in heap dumps (reported as `HPROF_GC_ROOT_MONITOR_USED`). As of this release, a weak reference is used. These are not observable to JVM TI or heap dumps. Consequently, `JVMTI_HEAP_ROOT_MONITOR`, `JVMTI_HEAP_REFERENCE_MONITOR` and `HPROF_GC_ROOT_MONITOR_USED` are longer reported. JDK-8257429: Deprecated Tracing Flags Are Obsolete and Must Be Replaced With Unified Logging Equivalents When Unified Logging was added in Java 9, a number of tracing flags were deprecated and mapped to their unified logging equivalent. These flags are now obsolete and will no longer be converted automatically to enable unified logging. To continue getting the same logging output, you must explicitly replace the use of these flags with their unified logging equivalent. | Obsoleted Option | Unified Logging Replacement | | ------------------------ | --------------------------- | | -XX:+TraceClassLoading | -Xlog:class+load=info | | -XX:+TraceClassUnloading | -Xlog:class+unload=info | | -XX:+TraceExceptions | -Xlog:exceptions=info | core-libs/java.util.logging: JDK-8247877: java.util.logging.LogRecord Updated to Support Long Thread IDs In this release, `java.util.logging.LogRecord` has been updated to support long thread ids. `LogRecord::getThreadID` and `LogRecord::setThreadID` are deprecated. New accessors, `LogRecord::getLongThreadID` and `LogRecord::setLongThreadID`, are provided and should be used instead. The serial field `threadID` has been deprecated and a new serial field `longThreadID` that can support long values has been introduced. The deprecated `threadID` field is kept in the serial form for backward compatibility. Long thread ids that are less than `Integer.MAX_VALUE` are directly mapped to `threadID` and `longThreadID` has the same value. For `longThreadID` greater than Integer.MAX_VALUE, a new negative value for the `int` `threadID` is synthesized by using a deterministic algorithm based on the `longThreadID` hash. The resulting value is guaranteed to be a negative value. core-libs/java.lang.module: JDK-8256310: Module::getPackages Returns the Set of Package Names in This Module `Module::getPackages` returns the set of package names for the packages in this module. For unnamed modules, the specification and implementation have been corrected to return the names of the packages defined in the unnamed module. Prior to Java SE 16, `Module::getPackages` returned the set of package names for the packages defined in the module's class loader if the module was an unnamed module and the result included packages of other named modules defined in the module's class loader, if any. security-libs/java.security: JDK-8259733: Added -trustcacerts and -keystore Options to keytool -printcert and -printcrl Commands The `-trustcacerts` and `-keystore` options have been added to the `-printcert` and `-printcrl` commands of the `keytool` utility. The `-printcert` command does not check for the weakness of a certificate's signature algorithm if it is a trusted certificate in the user's keystore or in the `cacerts` keystore. The `-printcrl` command verifies the CRL using a certificate from the user's keystore or the `cacerts` keystore, and will print out a warning if it cannot be verified. JDK-8248263: jarsigner Preserves POSIX File Permission and symlink Attributes When signing a file that contains POSIX file permission or symlink attributes, `jarsigner` now preserves these attributes in the newly signed file but warns that these attributes are unsigned and not protected by the signature. The same warning is printed during the `jarsigner -verify` operation for such files. Note that the `jar` tool does not read/write these attributes. This change is more visible to tools like `unzip` where these attributes are preserved. JDK-8242069: Upgraded the Default PKCS12 Encryption and MAC Algorithms The default encryption and MAC algorithms used in a PKCS #12 keystore have been updated. The new algorithms are based on AES-256 and SHA-256 and are stronger than the old algorithms that were based on RC2, DESede, and SHA-1. See the security properties starting with `keystore.pkcs12` in the `java.security` file for detailed information. For compatibility, a new system property named `keystore.pkcs12.legacy` is defined that will revert the algorithms to use the older, weaker algorithms. There is no value defined for this property. JDK-8256902: Removed Root Certificates with 1024-bit Keys The following root certificates with weak 1024-bit RSA public keys have been removed from the `cacerts` keystore: ``` + alias name "thawtepremiumserverca [jdk]"   Distinguished Name: EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA + alias name "verisignclass2g2ca [jdk]"   Distinguished Name: 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 + alias name "verisignclass3ca [jdk]"   Distinguished Name: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US + alias name "verisignclass3g2ca [jdk]"   Distinguished Name: 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 + alias name "verisigntsaca [jdk]"   Distinguished Name: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA ``` JDK-8253201: SUN, SunRsaSign, and SunEC Providers Supports SHA-3 Based Signature Algorithms SUN, SunRsaSign, and SunEC provider have been enhanced to support SHA-3 based signature algorithms. DSA signatures, RSA, and ECDSA signature implementations with SHA-3 family of digests are now supported through these providers. In addition, RSASSA-PSS signature implementation from SunRsaSign provider can recognize SHA-3 family of digests when specified in signature parameters. JDK-8250860: Added 3 SSL Corporation Root CA Certificates The following root certificates have been added to the cacerts truststore: ``` + SSL Corporation + sslrootrsaca DN: CN=SSL.com Root Certification Authority RSA, O=SSL Corporation, L=Houston, ST=Texas, C=US + sslrootevrsaca DN: CN=SSL.com EV Root Certification Authority RSA R2, O=SSL Corporation, L=Houston, ST=Texas, C=US + sslrooteccca DN: CN=SSL.com Root Certification Authority ECC, O=SSL Corporation, L=Houston, ST=Texas, C=US ``` JDK-8250756: Added Entrust Root Certification Authority - G4 certificate The following root certificate has been added to the cacerts truststore: ``` + Entrust + entrustrootcag4 DN: CN=Entrust Root Certification Authority - G4, OU="(c) 2015 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US ``` JDK-8252392: Deprecated the java.security.cert APIs That Represent DNs as Principal or String Objects The following APIs have been deprecated: ``` java.security.cert.X509Certificate.getIssuerDN() java.security.cert.X509Certificate.getSubjectDN() java.security.cert.X509CRL.getIssuerDN() java.security.cert.X509CertSelector.setIssuer(String) java.security.cert.X509CertSelector.setSubject(String) java.security.cert.X509CertSelector.getIssuerAsString() java.security.cert.X509CertSelector.getSubjectAsString() java.security.cert.X509CRLSelector.addIssuerName(String) ``` These APIs either take or return Distinguished Names as `Principal` or `String` objects and can cause issues due to loss of encoding information or differences when comparing names across different Principal implementations. All of them have alternative APIs that use `X500Principal` objects instead. JDK-8255132: Signed JAR Support for RSASSA-PSS and EdDSA This enhancement includes two main changes: 1. The JarSigner API and the `jarsigner` tool now support signing a JAR file with an RSASSA-PSS or EdDSA key. 2. Instead of signing the `.SF` file directly, `jarsigner` creates a [SignerInfo signedAttributes field](https://tools.ietf.org/html/rfc5652#section-11) which contains ContentType, MessageDigest, SigningTime, and [CMSAlgorithmProtection](https://tools.ietf.org/html/rfc6211). The field will not be generated if an alternative signing mechanism is specified by the `jarsigner` `-altsigner` option. Please note that although this field was not generated by `jarsigner` before this code change, it has always been supported when parsing the signature. This means newly signed JAR files with the field can be verified by earlier JDK releases. JDK-8259733: Added -trustcacerts and -keystore Options to keytool -printcert and -printcrl Commands The `-trustcacerts` and `-keystore` options have been added to the `-printcert` and `-printcrl` commands of the `keytool` utility. The `-printcert` command does not check for the weakness of a certificate's signature algorithm if it is a trusted certificate in the user's keystore or in the `cacerts` keystore. The `-printcrl` command verifies the CRL using a certificate from the user's keystore or the `cacerts` keystore, and will print out a warning if it cannot be verified. JDK-8248263: jarsigner Preserves POSIX File Permission and symlink Attributes When signing a file that contains POSIX file permission or symlink attributes, `jarsigner` now preserves these attributes in the newly signed file but warns that these attributes are unsigned and not protected by the signature. The same warning is printed during the `jarsigner -verify` operation for such files. Note that the `jar` tool does not read/write these attributes. This change is more visible to tools like `unzip` where these attributes are preserved. JDK-8242069: Upgraded the Default PKCS12 Encryption and MAC Algorithms The default encryption and MAC algorithms used in a PKCS #12 keystore have been updated. The new algorithms are based on AES-256 and SHA-256 and are stronger than the old algorithms that were based on RC2, DESede, and SHA-1. See the security properties starting with `keystore.pkcs12` in the `java.security` file for detailed information. For compatibility, a new system property named `keystore.pkcs12.legacy` is defined that will revert the algorithms to use the older, weaker algorithms. There is no value defined for this property. JDK-8256902: Removed Root Certificates with 1024-bit Keys The following root certificates with weak 1024-bit RSA public keys have been removed from the `cacerts` keystore: ``` + alias name "thawtepremiumserverca [jdk]"   Distinguished Name: EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA + alias name "verisignclass2g2ca [jdk]"   Distinguished Name: 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 + alias name "verisignclass3ca [jdk]"   Distinguished Name: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US + alias name "verisignclass3g2ca [jdk]"   Distinguished Name: 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 + alias name "verisigntsaca [jdk]"   Distinguished Name: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA ``` JDK-8253201: SUN, SunRsaSign, and SunEC Providers Supports SHA-3 Based Signature Algorithms SUN, SunRsaSign, and SunEC provider have been enhanced to support SHA-3 based signature algorithms. DSA signatures, RSA, and ECDSA signature implementations with SHA-3 family of digests are now supported through these providers. In addition, RSASSA-PSS signature implementation from SunRsaSign provider can recognize SHA-3 family of digests when specified in signature parameters. JDK-8250860: Added 3 SSL Corporation Root CA Certificates The following root certificates have been added to the cacerts truststore: ``` + SSL Corporation + sslrootrsaca DN: CN=SSL.com Root Certification Authority RSA, O=SSL Corporation, L=Houston, ST=Texas, C=US + sslrootevrsaca DN: CN=SSL.com EV Root Certification Authority RSA R2, O=SSL Corporation, L=Houston, ST=Texas, C=US + sslrooteccca DN: CN=SSL.com Root Certification Authority ECC, O=SSL Corporation, L=Houston, ST=Texas, C=US ``` JDK-8250756: Added Entrust Root Certification Authority - G4 certificate The following root certificate has been added to the cacerts truststore: ``` + Entrust + entrustrootcag4 DN: CN=Entrust Root Certification Authority - G4, OU="(c) 2015 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US ``` JDK-8252392: Deprecated the java.security.cert APIs That Represent DNs as Principal or String Objects The following APIs have been deprecated: ``` java.security.cert.X509Certificate.getIssuerDN() java.security.cert.X509Certificate.getSubjectDN() java.security.cert.X509CRL.getIssuerDN() java.security.cert.X509CertSelector.setIssuer(String) java.security.cert.X509CertSelector.setSubject(String) java.security.cert.X509CertSelector.getIssuerAsString() java.security.cert.X509CertSelector.getSubjectAsString() java.security.cert.X509CRLSelector.addIssuerName(String) ``` These APIs either take or return Distinguished Names as `Principal` or `String` objects and can cause issues due to loss of encoding information or differences when comparing names across different Principal implementations. All of them have alternative APIs that use `X500Principal` objects instead. JDK-8255132: Signed JAR Support for RSASSA-PSS and EdDSA This enhancement includes two main changes: 1. The JarSigner API and the `jarsigner` tool now support signing a JAR file with an RSASSA-PSS or EdDSA key. 2. Instead of signing the `.SF` file directly, `jarsigner` creates a [SignerInfo signedAttributes field](https://tools.ietf.org/html/rfc5652#section-11) which contains ContentType, MessageDigest, SigningTime, and [CMSAlgorithmProtection](https://tools.ietf.org/html/rfc6211). The field will not be generated if an alternative signing mechanism is specified by the `jarsigner` `-altsigner` option. Please note that although this field was not generated by `jarsigner` before this code change, it has always been supported when parsing the signature. This means newly signed JAR files with the field can be verified by earlier JDK releases. JDK-8259733: Added -trustcacerts and -keystore Options to keytool -printcert and -printcrl Commands The `-trustcacerts` and `-keystore` options have been added to the `-printcert` and `-printcrl` commands of the `keytool` utility. The `-printcert` command does not check for the weakness of a certificate's signature algorithm if it is a trusted certificate in the user's keystore or in the `cacerts` keystore. The `-printcrl` command verifies the CRL using a certificate from the user's keystore or the `cacerts` keystore, and will print out a warning if it cannot be verified. JDK-8248263: jarsigner Preserves POSIX File Permission and symlink Attributes When signing a file that contains POSIX file permission or symlink attributes, `jarsigner` now preserves these attributes in the newly signed file but warns that these attributes are unsigned and not protected by the signature. The same warning is printed during the `jarsigner -verify` operation for such files. Note that the `jar` tool does not read/write these attributes. This change is more visible to tools like `unzip` where these attributes are preserved. JDK-8242069: Upgraded the Default PKCS12 Encryption and MAC Algorithms The default encryption and MAC algorithms used in a PKCS #12 keystore have been updated. The new algorithms are based on AES-256 and SHA-256 and are stronger than the old algorithms that were based on RC2, DESede, and SHA-1. See the security properties starting with `keystore.pkcs12` in the `java.security` file for detailed information. For compatibility, a new system property named `keystore.pkcs12.legacy` is defined that will revert the algorithms to use the older, weaker algorithms. There is no value defined for this property. JDK-8256902: Removed Root Certificates with 1024-bit Keys The following root certificates with weak 1024-bit RSA public keys have been removed from the `cacerts` keystore: ``` + alias name "thawtepremiumserverca [jdk]"   Distinguished Name: EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA + alias name "verisignclass2g2ca [jdk]"   Distinguished Name: 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 + alias name "verisignclass3ca [jdk]"   Distinguished Name: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US + alias name "verisignclass3g2ca [jdk]"   Distinguished Name: 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 + alias name "verisigntsaca [jdk]"   Distinguished Name: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA ``` JDK-8253201: SUN, SunRsaSign, and SunEC Providers Supports SHA-3 Based Signature Algorithms SUN, SunRsaSign, and SunEC provider have been enhanced to support SHA-3 based signature algorithms. DSA signatures, RSA, and ECDSA signature implementations with SHA-3 family of digests are now supported through these providers. In addition, RSASSA-PSS signature implementation from SunRsaSign provider can recognize SHA-3 family of digests when specified in signature parameters. JDK-8250860: Added 3 SSL Corporation Root CA Certificates The following root certificates have been added to the cacerts truststore: ``` + SSL Corporation + sslrootrsaca DN: CN=SSL.com Root Certification Authority RSA, O=SSL Corporation, L=Houston, ST=Texas, C=US + sslrootevrsaca DN: CN=SSL.com EV Root Certification Authority RSA R2, O=SSL Corporation, L=Houston, ST=Texas, C=US + sslrooteccca DN: CN=SSL.com Root Certification Authority ECC, O=SSL Corporation, L=Houston, ST=Texas, C=US ``` JDK-8250756: Added Entrust Root Certification Authority - G4 certificate The following root certificate has been added to the cacerts truststore: ``` + Entrust + entrustrootcag4 DN: CN=Entrust Root Certification Authority - G4, OU="(c) 2015 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US ``` JDK-8252392: Deprecated the java.security.cert APIs That Represent DNs as Principal or String Objects The following APIs have been deprecated: ``` java.security.cert.X509Certificate.getIssuerDN() java.security.cert.X509Certificate.getSubjectDN() java.security.cert.X509CRL.getIssuerDN() java.security.cert.X509CertSelector.setIssuer(String) java.security.cert.X509CertSelector.setSubject(String) java.security.cert.X509CertSelector.getIssuerAsString() java.security.cert.X509CertSelector.getSubjectAsString() java.security.cert.X509CRLSelector.addIssuerName(String) ``` These APIs either take or return Distinguished Names as `Principal` or `String` objects and can cause issues due to loss of encoding information or differences when comparing names across different Principal implementations. All of them have alternative APIs that use `X500Principal` objects instead. JDK-8255132: Signed JAR Support for RSASSA-PSS and EdDSA This enhancement includes two main changes: 1. The JarSigner API and the `jarsigner` tool now support signing a JAR file with an RSASSA-PSS or EdDSA key. 2. Instead of signing the `.SF` file directly, `jarsigner` creates a [SignerInfo signedAttributes field](https://tools.ietf.org/html/rfc5652#section-11) which contains ContentType, MessageDigest, SigningTime, and [CMSAlgorithmProtection](https://tools.ietf.org/html/rfc6211). The field will not be generated if an alternative signing mechanism is specified by the `jarsigner` `-altsigner` option. Please note that although this field was not generated by `jarsigner` before this code change, it has always been supported when parsing the signature. This means newly signed JAR files with the field can be verified by earlier JDK releases. JDK-8259733: Added -trustcacerts and -keystore Options to keytool -printcert and -printcrl Commands The `-trustcacerts` and `-keystore` options have been added to the `-printcert` and `-printcrl` commands of the `keytool` utility. The `-printcert` command does not check for the weakness of a certificate's signature algorithm if it is a trusted certificate in the user's keystore or in the `cacerts` keystore. The `-printcrl` command verifies the CRL using a certificate from the user's keystore or the `cacerts` keystore, and will print out a warning if it cannot be verified. JDK-8248263: jarsigner Preserves POSIX File Permission and symlink Attributes When signing a file that contains POSIX file permission or symlink attributes, `jarsigner` now preserves these attributes in the newly signed file but warns that these attributes are unsigned and not protected by the signature. The same warning is printed during the `jarsigner -verify` operation for such files. Note that the `jar` tool does not read/write these attributes. This change is more visible to tools like `unzip` where these attributes are preserved. JDK-8242069: Upgraded the Default PKCS12 Encryption and MAC Algorithms The default encryption and MAC algorithms used in a PKCS #12 keystore have been updated. The new algorithms are based on AES-256 and SHA-256 and are stronger than the old algorithms that were based on RC2, DESede, and SHA-1. See the security properties starting with `keystore.pkcs12` in the `java.security` file for detailed information. For compatibility, a new system property named `keystore.pkcs12.legacy` is defined that will revert the algorithms to use the older, weaker algorithms. There is no value defined for this property. JDK-8256902: Removed Root Certificates with 1024-bit Keys The following root certificates with weak 1024-bit RSA public keys have been removed from the `cacerts` keystore: ``` + alias name "thawtepremiumserverca [jdk]"   Distinguished Name: EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA + alias name "verisignclass2g2ca [jdk]"   Distinguished Name: 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 + alias name "verisignclass3ca [jdk]"   Distinguished Name: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US + alias name "verisignclass3g2ca [jdk]"   Distinguished Name: 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 + alias name "verisigntsaca [jdk]"   Distinguished Name: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA ``` JDK-8253201: SUN, SunRsaSign, and SunEC Providers Supports SHA-3 Based Signature Algorithms SUN, SunRsaSign, and SunEC provider have been enhanced to support SHA-3 based signature algorithms. DSA signatures, RSA, and ECDSA signature implementations with SHA-3 family of digests are now supported through these providers. In addition, RSASSA-PSS signature implementation from SunRsaSign provider can recognize SHA-3 family of digests when specified in signature parameters. JDK-8250860: Added 3 SSL Corporation Root CA Certificates The following root certificates have been added to the cacerts truststore: ``` + SSL Corporation + sslrootrsaca DN: CN=SSL.com Root Certification Authority RSA, O=SSL Corporation, L=Houston, ST=Texas, C=US + sslrootevrsaca DN: CN=SSL.com EV Root Certification Authority RSA R2, O=SSL Corporation, L=Houston, ST=Texas, C=US + sslrooteccca DN: CN=SSL.com Root Certification Authority ECC, O=SSL Corporation, L=Houston, ST=Texas, C=US ``` JDK-8250756: Added Entrust Root Certification Authority - G4 certificate The following root certificate has been added to the cacerts truststore: ``` + Entrust + entrustrootcag4 DN: CN=Entrust Root Certification Authority - G4, OU="(c) 2015 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US ``` JDK-8252392: Deprecated the java.security.cert APIs That Represent DNs as Principal or String Objects The following APIs have been deprecated: ``` java.security.cert.X509Certificate.getIssuerDN() java.security.cert.X509Certificate.getSubjectDN() java.security.cert.X509CRL.getIssuerDN() java.security.cert.X509CertSelector.setIssuer(String) java.security.cert.X509CertSelector.setSubject(String) java.security.cert.X509CertSelector.getIssuerAsString() java.security.cert.X509CertSelector.getSubjectAsString() java.security.cert.X509CRLSelector.addIssuerName(String) ``` These APIs either take or return Distinguished Names as `Principal` or `String` objects and can cause issues due to loss of encoding information or differences when comparing names across different Principal implementations. All of them have alternative APIs that use `X500Principal` objects instead. JDK-8255132: Signed JAR Support for RSASSA-PSS and EdDSA This enhancement includes two main changes: 1. The JarSigner API and the `jarsigner` tool now support signing a JAR file with an RSASSA-PSS or EdDSA key. 2. Instead of signing the `.SF` file directly, `jarsigner` creates a [SignerInfo signedAttributes field](https://tools.ietf.org/html/rfc5652#section-11) which contains ContentType, MessageDigest, SigningTime, and [CMSAlgorithmProtection](https://tools.ietf.org/html/rfc6211). The field will not be generated if an alternative signing mechanism is specified by the `jarsigner` `-altsigner` option. Please note that although this field was not generated by `jarsigner` before this code change, it has always been supported when parsing the signature. This means newly signed JAR files with the field can be verified by earlier JDK releases. JDK-8259733: Added -trustcacerts and -keystore Options to keytool -printcert and -printcrl Commands The `-trustcacerts` and `-keystore` options have been added to the `-printcert` and `-printcrl` commands of the `keytool` utility. The `-printcert` command does not check for the weakness of a certificate's signature algorithm if it is a trusted certificate in the user's keystore or in the `cacerts` keystore. The `-printcrl` command verifies the CRL using a certificate from the user's keystore or the `cacerts` keystore, and will print out a warning if it cannot be verified. JDK-8248263: jarsigner Preserves POSIX File Permission and symlink Attributes When signing a file that contains POSIX file permission or symlink attributes, `jarsigner` now preserves these attributes in the newly signed file but warns that these attributes are unsigned and not protected by the signature. The same warning is printed during the `jarsigner -verify` operation for such files. Note that the `jar` tool does not read/write these attributes. This change is more visible to tools like `unzip` where these attributes are preserved. JDK-8242069: Upgraded the Default PKCS12 Encryption and MAC Algorithms The default encryption and MAC algorithms used in a PKCS #12 keystore have been updated. The new algorithms are based on AES-256 and SHA-256 and are stronger than the old algorithms that were based on RC2, DESede, and SHA-1. See the security properties starting with `keystore.pkcs12` in the `java.security` file for detailed information. For compatibility, a new system property named `keystore.pkcs12.legacy` is defined that will revert the algorithms to use the older, weaker algorithms. There is no value defined for this property. JDK-8256902: Removed Root Certificates with 1024-bit Keys The following root certificates with weak 1024-bit RSA public keys have been removed from the `cacerts` keystore: ``` + alias name "thawtepremiumserverca [jdk]"   Distinguished Name: EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA + alias name "verisignclass2g2ca [jdk]"   Distinguished Name: 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 + alias name "verisignclass3ca [jdk]"   Distinguished Name: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US + alias name "verisignclass3g2ca [jdk]"   Distinguished Name: 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 + alias name "verisigntsaca [jdk]"   Distinguished Name: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA ``` JDK-8253201: SUN, SunRsaSign, and SunEC Providers Supports SHA-3 Based Signature Algorithms SUN, SunRsaSign, and SunEC provider have been enhanced to support SHA-3 based signature algorithms. DSA signatures, RSA, and ECDSA signature implementations with SHA-3 family of digests are now supported through these providers. In addition, RSASSA-PSS signature implementation from SunRsaSign provider can recognize SHA-3 family of digests when specified in signature parameters. JDK-8250860: Added 3 SSL Corporation Root CA Certificates The following root certificates have been added to the cacerts truststore: ``` + SSL Corporation + sslrootrsaca DN: CN=SSL.com Root Certification Authority RSA, O=SSL Corporation, L=Houston, ST=Texas, C=US + sslrootevrsaca DN: CN=SSL.com EV Root Certification Authority RSA R2, O=SSL Corporation, L=Houston, ST=Texas, C=US + sslrooteccca DN: CN=SSL.com Root Certification Authority ECC, O=SSL Corporation, L=Houston, ST=Texas, C=US ``` JDK-8250756: Added Entrust Root Certification Authority - G4 certificate The following root certificate has been added to the cacerts truststore: ``` + Entrust + entrustrootcag4 DN: CN=Entrust Root Certification Authority - G4, OU="(c) 2015 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US ``` JDK-8252392: Deprecated the java.security.cert APIs That Represent DNs as Principal or String Objects The following APIs have been deprecated: ``` java.security.cert.X509Certificate.getIssuerDN() java.security.cert.X509Certificate.getSubjectDN() java.security.cert.X509CRL.getIssuerDN() java.security.cert.X509CertSelector.setIssuer(String) java.security.cert.X509CertSelector.setSubject(String) java.security.cert.X509CertSelector.getIssuerAsString() java.security.cert.X509CertSelector.getSubjectAsString() java.security.cert.X509CRLSelector.addIssuerName(String) ``` These APIs either take or return Distinguished Names as `Principal` or `String` objects and can cause issues due to loss of encoding information or differences when comparing names across different Principal implementations. All of them have alternative APIs that use `X500Principal` objects instead. JDK-8255132: Signed JAR Support for RSASSA-PSS and EdDSA This enhancement includes two main changes: 1. The JarSigner API and the `jarsigner` tool now support signing a JAR file with an RSASSA-PSS or EdDSA key. 2. Instead of signing the `.SF` file directly, `jarsigner` creates a [SignerInfo signedAttributes field](https://tools.ietf.org/html/rfc5652#section-11) which contains ContentType, MessageDigest, SigningTime, and [CMSAlgorithmProtection](https://tools.ietf.org/html/rfc6211). The field will not be generated if an alternative signing mechanism is specified by the `jarsigner` `-altsigner` option. Please note that although this field was not generated by `jarsigner` before this code change, it has always been supported when parsing the signature. This means newly signed JAR files with the field can be verified by earlier JDK releases. JDK-8259733: Added -trustcacerts and -keystore Options to keytool -printcert and -printcrl Commands The `-trustcacerts` and `-keystore` options have been added to the `-printcert` and `-printcrl` commands of the `keytool` utility. The `-printcert` command does not check for the weakness of a certificate's signature algorithm if it is a trusted certificate in the user's keystore or in the `cacerts` keystore. The `-printcrl` command verifies the CRL using a certificate from the user's keystore or the `cacerts` keystore, and will print out a warning if it cannot be verified. JDK-8248263: jarsigner Preserves POSIX File Permission and symlink Attributes When signing a file that contains POSIX file permission or symlink attributes, `jarsigner` now preserves these attributes in the newly signed file but warns that these attributes are unsigned and not protected by the signature. The same warning is printed during the `jarsigner -verify` operation for such files. Note that the `jar` tool does not read/write these attributes. This change is more visible to tools like `unzip` where these attributes are preserved. JDK-8242069: Upgraded the Default PKCS12 Encryption and MAC Algorithms The default encryption and MAC algorithms used in a PKCS #12 keystore have been updated. The new algorithms are based on AES-256 and SHA-256 and are stronger than the old algorithms that were based on RC2, DESede, and SHA-1. See the security properties starting with `keystore.pkcs12` in the `java.security` file for detailed information. For compatibility, a new system property named `keystore.pkcs12.legacy` is defined that will revert the algorithms to use the older, weaker algorithms. There is no value defined for this property. JDK-8256902: Removed Root Certificates with 1024-bit Keys The following root certificates with weak 1024-bit RSA public keys have been removed from the `cacerts` keystore: ``` + alias name "thawtepremiumserverca [jdk]"   Distinguished Name: EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA + alias name "verisignclass2g2ca [jdk]"   Distinguished Name: 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 + alias name "verisignclass3ca [jdk]"   Distinguished Name: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US + alias name "verisignclass3g2ca [jdk]"   Distinguished Name: 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 + alias name "verisigntsaca [jdk]"   Distinguished Name: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA ``` JDK-8253201: SUN, SunRsaSign, and SunEC Providers Supports SHA-3 Based Signature Algorithms SUN, SunRsaSign, and SunEC provider have been enhanced to support SHA-3 based signature algorithms. DSA signatures, RSA, and ECDSA signature implementations with SHA-3 family of digests are now supported through these providers. In addition, RSASSA-PSS signature implementation from SunRsaSign provider can recognize SHA-3 family of digests when specified in signature parameters. JDK-8250860: Added 3 SSL Corporation Root CA Certificates The following root certificates have been added to the cacerts truststore: ``` + SSL Corporation + sslrootrsaca DN: CN=SSL.com Root Certification Authority RSA, O=SSL Corporation, L=Houston, ST=Texas, C=US + sslrootevrsaca DN: CN=SSL.com EV Root Certification Authority RSA R2, O=SSL Corporation, L=Houston, ST=Texas, C=US + sslrooteccca DN: CN=SSL.com Root Certification Authority ECC, O=SSL Corporation, L=Houston, ST=Texas, C=US ``` JDK-8250756: Added Entrust Root Certification Authority - G4 certificate The following root certificate has been added to the cacerts truststore: ``` + Entrust + entrustrootcag4 DN: CN=Entrust Root Certification Authority - G4, OU="(c) 2015 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US ``` JDK-8252392: Deprecated the java.security.cert APIs That Represent DNs as Principal or String Objects The following APIs have been deprecated: ``` java.security.cert.X509Certificate.getIssuerDN() java.security.cert.X509Certificate.getSubjectDN() java.security.cert.X509CRL.getIssuerDN() java.security.cert.X509CertSelector.setIssuer(String) java.security.cert.X509CertSelector.setSubject(String) java.security.cert.X509CertSelector.getIssuerAsString() java.security.cert.X509CertSelector.getSubjectAsString() java.security.cert.X509CRLSelector.addIssuerName(String) ``` These APIs either take or return Distinguished Names as `Principal` or `String` objects and can cause issues due to loss of encoding information or differences when comparing names across different Principal implementations. All of them have alternative APIs that use `X500Principal` objects instead. JDK-8255132: Signed JAR Support for RSASSA-PSS and EdDSA This enhancement includes two main changes: 1. The JarSigner API and the `jarsigner` tool now support signing a JAR file with an RSASSA-PSS or EdDSA key. 2. Instead of signing the `.SF` file directly, `jarsigner` creates a [SignerInfo signedAttributes field](https://tools.ietf.org/html/rfc5652#section-11) which contains ContentType, MessageDigest, SigningTime, and [CMSAlgorithmProtection](https://tools.ietf.org/html/rfc6211). The field will not be generated if an alternative signing mechanism is specified by the `jarsigner` `-altsigner` option. Please note that although this field was not generated by `jarsigner` before this code change, it has always been supported when parsing the signature. This means newly signed JAR files with the field can be verified by earlier JDK releases. JDK-8259733: Added -trustcacerts and -keystore Options to keytool -printcert and -printcrl Commands The `-trustcacerts` and `-keystore` options have been added to the `-printcert` and `-printcrl` commands of the `keytool` utility. The `-printcert` command does not check for the weakness of a certificate's signature algorithm if it is a trusted certificate in the user's keystore or in the `cacerts` keystore. The `-printcrl` command verifies the CRL using a certificate from the user's keystore or the `cacerts` keystore, and will print out a warning if it cannot be verified. JDK-8248263: jarsigner Preserves POSIX File Permission and symlink Attributes When signing a file that contains POSIX file permission or symlink attributes, `jarsigner` now preserves these attributes in the newly signed file but warns that these attributes are unsigned and not protected by the signature. The same warning is printed during the `jarsigner -verify` operation for such files. Note that the `jar` tool does not read/write these attributes. This change is more visible to tools like `unzip` where these attributes are preserved. JDK-8242069: Upgraded the Default PKCS12 Encryption and MAC Algorithms The default encryption and MAC algorithms used in a PKCS #12 keystore have been updated. The new algorithms are based on AES-256 and SHA-256 and are stronger than the old algorithms that were based on RC2, DESede, and SHA-1. See the security properties starting with `keystore.pkcs12` in the `java.security` file for detailed information. For compatibility, a new system property named `keystore.pkcs12.legacy` is defined that will revert the algorithms to use the older, weaker algorithms. There is no value defined for this property. JDK-8256902: Removed Root Certificates with 1024-bit Keys The following root certificates with weak 1024-bit RSA public keys have been removed from the `cacerts` keystore: ``` + alias name "thawtepremiumserverca [jdk]"   Distinguished Name: EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA + alias name "verisignclass2g2ca [jdk]"   Distinguished Name: 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 + alias name "verisignclass3ca [jdk]"   Distinguished Name: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US + alias name "verisignclass3g2ca [jdk]"   Distinguished Name: 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 + alias name "verisigntsaca [jdk]"   Distinguished Name: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA ``` JDK-8253201: SUN, SunRsaSign, and SunEC Providers Supports SHA-3 Based Signature Algorithms SUN, SunRsaSign, and SunEC provider have been enhanced to support SHA-3 based signature algorithms. DSA signatures, RSA, and ECDSA signature implementations with SHA-3 family of digests are now supported through these providers. In addition, RSASSA-PSS signature implementation from SunRsaSign provider can recognize SHA-3 family of digests when specified in signature parameters. JDK-8250860: Added 3 SSL Corporation Root CA Certificates The following root certificates have been added to the cacerts truststore: ``` + SSL Corporation + sslrootrsaca DN: CN=SSL.com Root Certification Authority RSA, O=SSL Corporation, L=Houston, ST=Texas, C=US + sslrootevrsaca DN: CN=SSL.com EV Root Certification Authority RSA R2, O=SSL Corporation, L=Houston, ST=Texas, C=US + sslrooteccca DN: CN=SSL.com Root Certification Authority ECC, O=SSL Corporation, L=Houston, ST=Texas, C=US ``` JDK-8250756: Added Entrust Root Certification Authority - G4 certificate The following root certificate has been added to the cacerts truststore: ``` + Entrust + entrustrootcag4 DN: CN=Entrust Root Certification Authority - G4, OU="(c) 2015 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US ``` JDK-8252392: Deprecated the java.security.cert APIs That Represent DNs as Principal or String Objects The following APIs have been deprecated: ``` java.security.cert.X509Certificate.getIssuerDN() java.security.cert.X509Certificate.getSubjectDN() java.security.cert.X509CRL.getIssuerDN() java.security.cert.X509CertSelector.setIssuer(String) java.security.cert.X509CertSelector.setSubject(String) java.security.cert.X509CertSelector.getIssuerAsString() java.security.cert.X509CertSelector.getSubjectAsString() java.security.cert.X509CRLSelector.addIssuerName(String) ``` These APIs either take or return Distinguished Names as `Principal` or `String` objects and can cause issues due to loss of encoding information or differences when comparing names across different Principal implementations. All of them have alternative APIs that use `X500Principal` objects instead. JDK-8255132: Signed JAR Support for RSASSA-PSS and EdDSA This enhancement includes two main changes: 1. The JarSigner API and the `jarsigner` tool now support signing a JAR file with an RSASSA-PSS or EdDSA key. 2. Instead of signing the `.SF` file directly, `jarsigner` creates a [SignerInfo signedAttributes field](https://tools.ietf.org/html/rfc5652#section-11) which contains ContentType, MessageDigest, SigningTime, and [CMSAlgorithmProtection](https://tools.ietf.org/html/rfc6211). The field will not be generated if an alternative signing mechanism is specified by the `jarsigner` `-altsigner` option. Please note that although this field was not generated by `jarsigner` before this code change, it has always been supported when parsing the signature. This means newly signed JAR files with the field can be verified by earlier JDK releases. JDK-8259733: Added -trustcacerts and -keystore Options to keytool -printcert and -printcrl Commands The `-trustcacerts` and `-keystore` options have been added to the `-printcert` and `-printcrl` commands of the `keytool` utility. The `-printcert` command does not check for the weakness of a certificate's signature algorithm if it is a trusted certificate in the user's keystore or in the `cacerts` keystore. The `-printcrl` command verifies the CRL using a certificate from the user's keystore or the `cacerts` keystore, and will print out a warning if it cannot be verified. JDK-8248263: jarsigner Preserves POSIX File Permission and symlink Attributes When signing a file that contains POSIX file permission or symlink attributes, `jarsigner` now preserves these attributes in the newly signed file but warns that these attributes are unsigned and not protected by the signature. The same warning is printed during the `jarsigner -verify` operation for such files. Note that the `jar` tool does not read/write these attributes. This change is more visible to tools like `unzip` where these attributes are preserved. JDK-8242069: Upgraded the Default PKCS12 Encryption and MAC Algorithms The default encryption and MAC algorithms used in a PKCS #12 keystore have been updated. The new algorithms are based on AES-256 and SHA-256 and are stronger than the old algorithms that were based on RC2, DESede, and SHA-1. See the security properties starting with `keystore.pkcs12` in the `java.security` file for detailed information. For compatibility, a new system property named `keystore.pkcs12.legacy` is defined that will revert the algorithms to use the older, weaker algorithms. There is no value defined for this property. JDK-8256902: Removed Root Certificates with 1024-bit Keys The following root certificates with weak 1024-bit RSA public keys have been removed from the `cacerts` keystore: ``` + alias name "thawtepremiumserverca [jdk]"   Distinguished Name: EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA + alias name "verisignclass2g2ca [jdk]"   Distinguished Name: 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 + alias name "verisignclass3ca [jdk]"   Distinguished Name: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US + alias name "verisignclass3g2ca [jdk]"   Distinguished Name: 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 + alias name "verisigntsaca [jdk]"   Distinguished Name: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA ``` JDK-8253201: SUN, SunRsaSign, and SunEC Providers Supports SHA-3 Based Signature Algorithms SUN, SunRsaSign, and SunEC provider have been enhanced to support SHA-3 based signature algorithms. DSA signatures, RSA, and ECDSA signature implementations with SHA-3 family of digests are now supported through these providers. In addition, RSASSA-PSS signature implementation from SunRsaSign provider can recognize SHA-3 family of digests when specified in signature parameters. JDK-8250860: Added 3 SSL Corporation Root CA Certificates The following root certificates have been added to the cacerts truststore: ``` + SSL Corporation + sslrootrsaca DN: CN=SSL.com Root Certification Authority RSA, O=SSL Corporation, L=Houston, ST=Texas, C=US + sslrootevrsaca DN: CN=SSL.com EV Root Certification Authority RSA R2, O=SSL Corporation, L=Houston, ST=Texas, C=US + sslrooteccca DN: CN=SSL.com Root Certification Authority ECC, O=SSL Corporation, L=Houston, ST=Texas, C=US ``` JDK-8250756: Added Entrust Root Certification Authority - G4 certificate The following root certificate has been added to the cacerts truststore: ``` + Entrust + entrustrootcag4 DN: CN=Entrust Root Certification Authority - G4, OU="(c) 2015 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US ``` JDK-8252392: Deprecated the java.security.cert APIs That Represent DNs as Principal or String Objects The following APIs have been deprecated: ``` java.security.cert.X509Certificate.getIssuerDN() java.security.cert.X509Certificate.getSubjectDN() java.security.cert.X509CRL.getIssuerDN() java.security.cert.X509CertSelector.setIssuer(String) java.security.cert.X509CertSelector.setSubject(String) java.security.cert.X509CertSelector.getIssuerAsString() java.security.cert.X509CertSelector.getSubjectAsString() java.security.cert.X509CRLSelector.addIssuerName(String) ``` These APIs either take or return Distinguished Names as `Principal` or `String` objects and can cause issues due to loss of encoding information or differences when comparing names across different Principal implementations. All of them have alternative APIs that use `X500Principal` objects instead. JDK-8255132: Signed JAR Support for RSASSA-PSS and EdDSA This enhancement includes two main changes: 1. The JarSigner API and the `jarsigner` tool now support signing a JAR file with an RSASSA-PSS or EdDSA key. 2. Instead of signing the `.SF` file directly, `jarsigner` creates a [SignerInfo signedAttributes field](https://tools.ietf.org/html/rfc5652#section-11) which contains ContentType, MessageDigest, SigningTime, and [CMSAlgorithmProtection](https://tools.ietf.org/html/rfc6211). The field will not be generated if an alternative signing mechanism is specified by the `jarsigner` `-altsigner` option. Please note that although this field was not generated by `jarsigner` before this code change, it has always been supported when parsing the signature. This means newly signed JAR files with the field can be verified by earlier JDK releases. JDK-8259733: Added -trustcacerts and -keystore Options to keytool -printcert and -printcrl Commands The `-trustcacerts` and `-keystore` options have been added to the `-printcert` and `-printcrl` commands of the `keytool` utility. The `-printcert` command does not check for the weakness of a certificate's signature algorithm if it is a trusted certificate in the user's keystore or in the `cacerts` keystore. The `-printcrl` command verifies the CRL using a certificate from the user's keystore or the `cacerts` keystore, and will print out a warning if it cannot be verified. JDK-8248263: jarsigner Preserves POSIX File Permission and symlink Attributes When signing a file that contains POSIX file permission or symlink attributes, `jarsigner` now preserves these attributes in the newly signed file but warns that these attributes are unsigned and not protected by the signature. The same warning is printed during the `jarsigner -verify` operation for such files. Note that the `jar` tool does not read/write these attributes. This change is more visible to tools like `unzip` where these attributes are preserved. JDK-8242069: Upgraded the Default PKCS12 Encryption and MAC Algorithms The default encryption and MAC algorithms used in a PKCS #12 keystore have been updated. The new algorithms are based on AES-256 and SHA-256 and are stronger than the old algorithms that were based on RC2, DESede, and SHA-1. See the security properties starting with `keystore.pkcs12` in the `java.security` file for detailed information. For compatibility, a new system property named `keystore.pkcs12.legacy` is defined that will revert the algorithms to use the older, weaker algorithms. There is no value defined for this property. JDK-8256902: Removed Root Certificates with 1024-bit Keys The following root certificates with weak 1024-bit RSA public keys have been removed from the `cacerts` keystore: ``` + alias name "thawtepremiumserverca [jdk]"   Distinguished Name: EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA + alias name "verisignclass2g2ca [jdk]"   Distinguished Name: 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 + alias name "verisignclass3ca [jdk]"   Distinguished Name: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US + alias name "verisignclass3g2ca [jdk]"   Distinguished Name: 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 + alias name "verisigntsaca [jdk]"   Distinguished Name: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA ``` JDK-8253201: SUN, SunRsaSign, and SunEC Providers Supports SHA-3 Based Signature Algorithms SUN, SunRsaSign, and SunEC provider have been enhanced to support SHA-3 based signature algorithms. DSA signatures, RSA, and ECDSA signature implementations with SHA-3 family of digests are now supported through these providers. In addition, RSASSA-PSS signature implementation from SunRsaSign provider can recognize SHA-3 family of digests when specified in signature parameters. JDK-8250860: Added 3 SSL Corporation Root CA Certificates The following root certificates have been added to the cacerts truststore: ``` + SSL Corporation + sslrootrsaca DN: CN=SSL.com Root Certification Authority RSA, O=SSL Corporation, L=Houston, ST=Texas, C=US + sslrootevrsaca DN: CN=SSL.com EV Root Certification Authority RSA R2, O=SSL Corporation, L=Houston, ST=Texas, C=US + sslrooteccca DN: CN=SSL.com Root Certification Authority ECC, O=SSL Corporation, L=Houston, ST=Texas, C=US ``` JDK-8250756: Added Entrust Root Certification Authority - G4 certificate The following root certificate has been added to the cacerts truststore: ``` + Entrust + entrustrootcag4 DN: CN=Entrust Root Certification Authority - G4, OU="(c) 2015 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US ``` JDK-8252392: Deprecated the java.security.cert APIs That Represent DNs as Principal or String Objects The following APIs have been deprecated: ``` java.security.cert.X509Certificate.getIssuerDN() java.security.cert.X509Certificate.getSubjectDN() java.security.cert.X509CRL.getIssuerDN() java.security.cert.X509CertSelector.setIssuer(String) java.security.cert.X509CertSelector.setSubject(String) java.security.cert.X509CertSelector.getIssuerAsString() java.security.cert.X509CertSelector.getSubjectAsString() java.security.cert.X509CRLSelector.addIssuerName(String) ``` These APIs either take or return Distinguished Names as `Principal` or `String` objects and can cause issues due to loss of encoding information or differences when comparing names across different Principal implementations. All of them have alternative APIs that use `X500Principal` objects instead. JDK-8255132: Signed JAR Support for RSASSA-PSS and EdDSA This enhancement includes two main changes: 1. The JarSigner API and the `jarsigner` tool now support signing a JAR file with an RSASSA-PSS or EdDSA key. 2. Instead of signing the `.SF` file directly, `jarsigner` creates a [SignerInfo signedAttributes field](https://tools.ietf.org/html/rfc5652#section-11) which contains ContentType, MessageDigest, SigningTime, and [CMSAlgorithmProtection](https://tools.ietf.org/html/rfc6211). The field will not be generated if an alternative signing mechanism is specified by the `jarsigner` `-altsigner` option. Please note that although this field was not generated by `jarsigner` before this code change, it has always been supported when parsing the signature. This means newly signed JAR files with the field can be verified by earlier JDK releases. core-libs/java.lang:reflect: JDK-8263045: Add InvocationHandler::invokeDefault Method for Proxy's Default Method Support A new method, `invokeDefault`, has been added to the `java.lang.reflect.InvocationHandler` interface to allow a default method defined in a proxy interface to be invoked. JDK-8260600: Proxy Classes Are Not Open for Reflective Access All proxy classes are not open for reflective access in Java SE 16. Prior to Java SE 16, if `java.lang.reflect.Proxy` was used to implement only public exported proxy interfaces, the proxy class was generated in an unnamed module which was open for reflective access. In Java SE 16, the proxy class is generated in an exported package in a named module. Programs that assume the private members of a proxy class can be made accessible via `setAccessible(true)` will fail with `InaccessibleObjectException`. Proxy classes are already defined in dynamic modules in other cases since Java SE 9. Such programs would already fail when it calls `setAccessible(true)` to those proxy classes prior to this change. core-libs/java.time: JDK-8254679: US/Pacific-New Zone Name Removed as Part of tzdata2020b Following the JDK's update to tzdata2020b, the long-obsolete files named `pacificnew` and `systemv` have been removed. As a result, the "US/Pacific-New" Zone name declared in the `pacificnew` data file is no longer available for use. Information regarding this update can be viewed at https://mm.icann.org/pipermail/tz-announce/2020-October/000059.html JDK-8255971: Day Period Support Added to java.time Formats A new formatter pattern, letter 'B', and its supporting method have been added to `java.time.format.DateTimeFormatter/DateTimeFormatterBuilder` classes. The pattern and method translate `day periods` defined in Unicode Consortium's CLDR (https://unicode.org/reports/tr35/tr35-dates.html#dayPeriods). Applications can now express periods in a day, such as "in the morning" or "at night", not just am/pm. The following example demonstrates translating the day periods: ``` DateTimeFormatter.ofPattern("B").format(LocalTime.now()) ``` This example produces day period text depending on the time of the day and locale. JDK-8254679: US/Pacific-New Zone Name Removed as Part of tzdata2020b Following the JDK's update to tzdata2020b, the long-obsolete files named `pacificnew` and `systemv` have been removed. As a result, the "US/Pacific-New" Zone name declared in the `pacificnew` data file is no longer available for use. Information regarding this update can be viewed at https://mm.icann.org/pipermail/tz-announce/2020-October/000059.html JDK-8255971: Day Period Support Added to java.time Formats A new formatter pattern, letter 'B', and its supporting method have been added to `java.time.format.DateTimeFormatter/DateTimeFormatterBuilder` classes. The pattern and method translate `day periods` defined in Unicode Consortium's CLDR (https://unicode.org/reports/tr35/tr35-dates.html#dayPeriods). Applications can now express periods in a day, such as "in the morning" or "at night", not just am/pm. The following example demonstrates translating the day periods: ``` DateTimeFormatter.ofPattern("B").format(LocalTime.now()) ``` This example produces day period text depending on the time of the day and locale. core-libs/java.util.stream: JDK-8257870: Add Stream.toList() Method A new method `toList` has been added to the `java.util.Stream` interface. This introduces a potential source incompatibility with classes that implement or interfaces that extend the `Stream` interface and that also statically import a `toList` method from elsewhere, for example, `Collectors.toList`. References to such methods must be changed to use a qualified name instead of a static import. tools/jpackage: JDK-8262050: JEP 392: Packaging Tool Provides the `jpackage` tool, for packaging self-contained Java applications. The `jpackage tool` was introduced as an incubating tool in JDK 14 by JEP 343. It remained an incubating tool in JDK 15, to allow time for additional feedback. It has been promoted in JDK 16 from incubation to a production-ready feature. As a consequence of this transition, the name of the `jpackage` module has changed from `jdk.incubator.jpackage` to `jdk.jpackage`. For further details, see [JEP 392](https://openjdk.java.net/jeps/392). core-libs: JDK-8256358: JEP 396: Strongly Encapsulate JDK Internals by Default Strongly encapsulate all internal elements of the JDK by default, except for [critical internal APIs][crit] such as `sun.misc.Unsafe`. Allow end users to choose the relaxed strong encapsulation that has been the default since JDK 9. With this change, the default value of the launcher option [`--illegal-access`][relax] is now `deny` rather than `permit`. As a consequence, existing code that uses most internal classes, methods, or fields of the JDK will fail to run. Such code can be made to run on JDK 16 by specifying `--illegal-access=permit`. That option will, however, be removed in a future release. For further details, please see [JEP 396](https://openjdk.java.net/jeps/396). [crit]: https://openjdk.java.net/jeps/260#Description [relax]: https://openjdk.java.net/jeps/261#Relaxed-strong-encapsulation JDK-8262789: JEP 389: Foreign Linker API (Incubator) Introduce an API that offers statically-typed, pure-Java access to native code. This API, together with the Foreign-Memory API (JEP 393), will considerably simplify the otherwise error-prone process of binding to a native library. For further details, see [JEP 389](https://openjdk.java.net/jeps/389). JDK-8262791: JEP 393: Foreign-Memory Access API (Third Incubator) Introduce an API to allow Java programs to safely and efficiently access foreign memory outside of the Java heap. For further details, see [JEP 393](https://openjdk.java.net/jeps/393). JDK-8256358: JEP 396: Strongly Encapsulate JDK Internals by Default Strongly encapsulate all internal elements of the JDK by default, except for [critical internal APIs][crit] such as `sun.misc.Unsafe`. Allow end users to choose the relaxed strong encapsulation that has been the default since JDK 9. With this change, the default value of the launcher option [`--illegal-access`][relax] is now `deny` rather than `permit`. As a consequence, existing code that uses most internal classes, methods, or fields of the JDK will fail to run. Such code can be made to run on JDK 16 by specifying `--illegal-access=permit`. That option will, however, be removed in a future release. For further details, please see [JEP 396](https://openjdk.java.net/jeps/396). [crit]: https://openjdk.java.net/jeps/260#Description [relax]: https://openjdk.java.net/jeps/261#Relaxed-strong-encapsulation JDK-8262789: JEP 389: Foreign Linker API (Incubator) Introduce an API that offers statically-typed, pure-Java access to native code. This API, together with the Foreign-Memory API (JEP 393), will considerably simplify the otherwise error-prone process of binding to a native library. For further details, see [JEP 389](https://openjdk.java.net/jeps/389). JDK-8262791: JEP 393: Foreign-Memory Access API (Third Incubator) Introduce an API to allow Java programs to safely and efficiently access foreign memory outside of the Java heap. For further details, see [JEP 393](https://openjdk.java.net/jeps/393). JDK-8256358: JEP 396: Strongly Encapsulate JDK Internals by Default Strongly encapsulate all internal elements of the JDK by default, except for [critical internal APIs][crit] such as `sun.misc.Unsafe`. Allow end users to choose the relaxed strong encapsulation that has been the default since JDK 9. With this change, the default value of the launcher option [`--illegal-access`][relax] is now `deny` rather than `permit`. As a consequence, existing code that uses most internal classes, methods, or fields of the JDK will fail to run. Such code can be made to run on JDK 16 by specifying `--illegal-access=permit`. That option will, however, be removed in a future release. For further details, please see [JEP 396](https://openjdk.java.net/jeps/396). [crit]: https://openjdk.java.net/jeps/260#Description [relax]: https://openjdk.java.net/jeps/261#Relaxed-strong-encapsulation JDK-8262789: JEP 389: Foreign Linker API (Incubator) Introduce an API that offers statically-typed, pure-Java access to native code. This API, together with the Foreign-Memory API (JEP 393), will considerably simplify the otherwise error-prone process of binding to a native library. For further details, see [JEP 389](https://openjdk.java.net/jeps/389). JDK-8262791: JEP 393: Foreign-Memory Access API (Third Incubator) Introduce an API to allow Java programs to safely and efficiently access foreign memory outside of the Java heap. For further details, see [JEP 393](https://openjdk.java.net/jeps/393). core-libs/javax.naming: JDK-8258824: LDAP Channel Binding Support for Java GSS/Kerberos A new JNDI environment property `“com.sun.jndi.ldap.tls.cbtype”` has been added to enable TLS Channel Binding data in LDAP authentication over SSL/TLS protocol to the Windows AD server. Possible value is `“tls-server-end-point”` - Channel Binding data is created on the base of the TLS server certificate. See the module description of the `java.naming` module. core-libs/java.util.jar: JDK-8253185: GZIPOutputStream Sets the GZIP OS Header Field to the Correct Default Value Prior to JDK 16, GZIPOutputStream set the OS field in the GZIP header to 0 (meaning FAT filesystem), which does not match the default value specified in section 2.3.1.2 of the GZIP file format specification version 4.3 (RFC 1952). As of JDK 16, the GZIP OS Header Field is set to 255, which is the default value as defined in RFC 1952. JDK-8254840: Refine ZipOutputStream.putNextEntry() to Recalculate ZipEntry's Compressed Size Prior to JDK 16, `ZipOutputStream.putnextEntry()` would not recalculate the compressed size for a compressed (DEFLATED) entry. This could result in the ZipException, "invalid entry compressed size", being thrown if the current ZLIB implementation being used when `ZipOutputStream.putNextEntry()` was called differed from the implementation at the time when the entry was added to the original ZIP file. Starting with JDK 16, if the compressed size has not been explicitly set with the `ZipEntry.setCompressedSize(long)` method when writing a compressed (DEFLATED) entry, then the compressed size is set to the actual compressed size after deflation. JDK-8253185: GZIPOutputStream Sets the GZIP OS Header Field to the Correct Default Value Prior to JDK 16, GZIPOutputStream set the OS field in the GZIP header to 0 (meaning FAT filesystem), which does not match the default value specified in section 2.3.1.2 of the GZIP file format specification version 4.3 (RFC 1952). As of JDK 16, the GZIP OS Header Field is set to 255, which is the default value as defined in RFC 1952. JDK-8254840: Refine ZipOutputStream.putNextEntry() to Recalculate ZipEntry's Compressed Size Prior to JDK 16, `ZipOutputStream.putnextEntry()` would not recalculate the compressed size for a compressed (DEFLATED) entry. This could result in the ZipException, "invalid entry compressed size", being thrown if the current ZLIB implementation being used when `ZipOutputStream.putNextEntry()` was called differed from the implementation at the time when the entry was added to the original ZIP file. Starting with JDK 16, if the compressed size has not been explicitly set with the `ZipEntry.setCompressedSize(long)` method when writing a compressed (DEFLATED) entry, then the compressed size is set to the actual compressed size after deflation. hotspot/compiler: JDK-8255623: Removal of Experimental Features AOT and Graal JIT The Java Ahead-of-Time compilation experimental tool `jaotc` has been removed. Using HotSpot VM options defined by [JEP295](https://openjdk.java.net/jeps/295) produce a not supported option warning but will otherwise be ignored. The experimental Java-based JIT compiler, Graal [JEP317](https://openjdk.java.net/jeps/317), has been removed. Attempting to use it produces a JVMCI error: `JVMCI compiler 'graal' not found`. JDK-8261369: JEP 338: Vector API (Incubator) Provides an initial iteration of an incubator module, `jdk.incubator.vector`, to express vector computations that reliably compile at runtime to optimal vector hardware instructions on supported CPU architectures and thus achieve superior performance to equivalent scalar computations. For further details, see [JEP 338](https://openjdk.java.net/jeps/338). JDK-8263032: Improved CompileCommand Flag The CompileCommand flag has an option type that has been used for a collection of sub commands. These commands weren't verified for validity so spelling mistakes lead to the command being ignored. They had the form: ``` -XX:CompileCommand=option,,