RELEASE NOTES FOR: 16 ==================================================================================================== Notes generated: Tue Jun 01 07:15:36 CEST 2021 JIRA Query: project = JDK AND (status in (Closed, Resolved)) AND (resolution not in ("Won't Fix", Duplicate, "Cannot Reproduce", "Not an Issue", Withdrawn)) AND (labels not in (release-note, testbug, openjdk-na, testbug) OR labels is EMPTY) AND (summary !~ 'testbug') AND (summary !~ 'problemlist') AND (summary !~ 'problem list') AND (summary !~ 'release note') AND (issuetype != CSR) AND fixVersion = 16 Acquiring pages (2488 total): .................................................. done Loading issues (2488 total): .................................................. done Resolving issues (2488 total): ................................................. done Resolving parents (2488 total): ................................................. done Resolving backports (2488 total): ................................................. done JIRA Query: project = JDK AND issuetype = JEP AND fixVersion = 16 ORDER BY summary ASC Acquiring pages (17 total): . done Loading issues (17 total): . done Resolving issues (17 total): done Resolving parents (17 total): done Filtered 227 issues carried over, 2256 pushes left. 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. 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). client-libs/java.awt: JDK-8254970: Removal of java.awt.PeerFixer The non-public class `java.awt.PeerFixer` has been removed in this release. This class was used to provide deserialization support of ScrollPane objects created prior JDK 1.1.1. 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). core-libs/java.io: JDK-8260874: Line Terminator Definition Changed in java.io.LineNumberReader The definition of line terminator has been extended to include end of stream, or one of the previously defined line terminators `'\n'`, `'\r'`, or `'\r`\`n'` followed immediately by end of stream. This changes behavior in certain cases. For example, a file containing the lines 
line 1\n line 2\n line 3
would, before this change, have been considered to contain two lines, each terminated by '\n'. After this change, it is considered to contain three lines, the third being terminated by end of stream. 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. 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. core-libs/java.lang:reflect: 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. 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. 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. core-libs/java.nio: JDK-8260872: (fs) NullPointerException Not Thrown When First Argument to Path.of or Paths.get Is null The var args form of `Path.of()` and `Paths.get()` method are changed in this release to throw `NullPointerException` consistently when the first parameter is null. Historically these methods missed a null check on the first parameter when invoked with more than one parameter. JDK-8259579: Incomplete Support for Unix Domain Sockets in Windows 2019 Server JEP 380: Unix-Domain Socket Channels has been integrated into JDK 16, but due to a problem with the underlying implementation in Windows 2019 Server, it has been disabled on that platform in this release. The functionality is supported on Linux, macOS and on Windows operating systems whose build number is 18362 or greater. This includes Windows 10 (Version 1903) and newer. There are no known issues with Windows 10 (Version 1903). However, some newer versions of Windows 10 may also show the problem, which affects the ability of some native tools (such as cygwin) to access and delete socket files. Other Java APIs are also affected by the problem, but most native Windows tools are not affected by it. More information can be seen in bugs JDK-8259014 and JDK-8252971. This issue will be resolved in JDK 17 and in a future update to JDK 16. JDK-8262130: JEP 380: Unix domain sockets Provides support for Unix domain sockets (AF_UNIX) in the `java.nio.channels`, `SocketChannel`, and `ServerSocketChannel` classes. See [JEP-380](https://openjdk.java.net/jeps/380) for more information. See also the following [release note](https://bugs.openjdk.java.net/browse/JDK-8259579) for information about the limitations in the support on Windows in JDK16. 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. 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.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. 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.util.regex: JDK-8258456: Incorrect behavior matching Unicode linebreaks The change JDK-8235812 in Java 15 introduced incorrect behavior for matching of the `\R` Unicode linebreak sequence when using the `java.util.regex.Pattern` API. The `\R` sequence should match CR (U+000D) or LF (U+000A) individually, but it should not match an individual CR if it occurs in a CRLF sequence. An example of the erroneous behavior is that the pattern `\R{2}` matches a CRLF sequence, but it should not. A possible workaround is to match linebreaks using individual characters instead of `\R`, using negative lookahead to prevent matching of an individual CR within a CRLF sequence. To do this, replace the `\R` sequence with the following: ``` (?:(\u000D\u000A)|((?!\u000D\u000A)[\000A\u000B\u000C\u000D\u0085\u2028\u2029])) ``` A simpler sequence can be used if matching all of the Unicode-specified linebreak characters is not required, or if special treatment for the CRLF sequence is not required. 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. 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/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. hotspot/compiler: 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,,