Bad EnclosingMethod Attribute on Classes Declared in Lambdas

If an anonymous or local inner class is declared inside of a lambda, the EnclosingMethod attribute on that class refers to the synthetic lambda method rather than to the method that enclosed the original declaration. The original method should be considered as the closest lexically enclosing method.

The proposed solution to this issue is to point the EnclosingMethod attribute of inner classes declared inside a lambda to the original enclosing method. The Java compiler was updated, so that the EnclosingMethod attribute of anonymous or local inner classes declared inside a lambda point to the method enclosing the declaration.

The following is the related section in the Java Language Specification: JVMS 11 4.7.7: It is the responsibility of a Java compiler to ensure that the method identified via the method_index is indeed the closest lexically enclosing method of the class that contains this EnclosingMethod attribute.

javac Rejects Class Files with Broken EnclosingMethod Attribute

javac now rejects class files that have an invalid EnclosingMethod attribute, in which the name of the enclosing class is not a prefix of the name of the current class, as required by JLS 13.1.

Properties Files Containing Malformed Unicode Was Sometimes Misparsed

An IllegalArgumentException is always thrown now when loading a properties file with malformed unicode sequences. Previously, a malformed unicode sequence appearing at the end of a line was parsed using the contents of the preceding line, which in rare cases meant it could be parsed as a valid (but likely incorrect) sequence.

Base64.Encoder and Base64.Decoder Methods Can Throw OutOfMemoryError

The behavior of Base64.Encoder.encode and Base64.Decoder.decode methods have been changed for large arrays. The methods previously threw an unspecified exception, such as, NegativeArraySizeException. The new behavior throws an OutOfMemoryError exception if the encode and decode methods fail to allocate the output array/buffer or memory.

Change to ServerSocket.accept() When the System-Wide Factory for Client or Server Socket Implementations Is Set

Developers using the java.net.Socket.setSocketImplFactory or java.net.ServerSocket.setSocketFactory APIs to change the system-wide factories for client socket or server socket implementations should note the following changes:

1. Invoking ServerSocket::accept on a ServerSocket using a system-default SocketImpl to accept a connection will always return a Socket with a system-default SocketImpl. In this case, the system-wide factory for client socket implementations will not be invoked to create the client socket implementation.

2. java.net.ServerSocket::implAccept has been changed to disallow a ServerSocket using a system-default SocketImpl from accepting a connection with a Socket using a custom SocketImpl. It has also been changed to disallow a ServerSocket using a custom SocketImpl to accept a connection with a Socket using a system-default SocketImpl. Disallowing these nonsensical combinations of SocketImpl improves reliability in cases where an application sets one, but not both, socket implementation factories.

The changes should have no impact on applications that set the same factory for both client and server socket implementations.

Change to Default Implementation of SocketImpl Methods supportedOptions, getOption, and setOption

The default implementation of the supportedOptions(), getOption(SocketOption<T>) and setOption(SocketOption<T>, T) methods, defined by java.net.SocketImpl and java.net.DatagramSocketImpl, have changed in this release. The default implementation of the supportedOptions() method has been changed to return an empty set. The default implementations of the getOption(SocketOption<T>) and setOption(SocketOption<T>, T) methods have been changed to throw UnsupportedOperationException.

Developers extending java.net.SocketImpl or java.net.DatagramSocketImpl to create their own socket or datagram socket implementations need to override these methods to support the socket options that the custom socket implementation supports.

Pre-JDK 1.4 SocketImpl Implementations No Longer Supported

Support for custom java.net.SocketImpl implementations compiled for Java SE 1.3 and older has been removed in this release. This change has no impact on SocketImpl implementations compiled for Java SE 1.4 (released in 2002) or newer.

JEP 353: Reimplement the Legacy Socket API

The underlying implementation for the java.net.Socket and java.net.ServerSocket APIs has been replaced in this release. JEP 353 provides all the details on this change.

Every effort has been made to ensure that the new implementation is compatible with the old implementation but it is possible that there is existing code that depends on unspecified behavior in corner cases where the old and new implementations behave differently. The JDK continues to include the old implementation (known as "PlainSocketImpl" or the "plain" implementation) to allow such code continue to run. The old implementation is selected by running with the system property "jdk.net.usePlainSockteImpl" set, or set to the value "true", i.e. run with -Djdk.net.usePlainSocketImpl or -Djdk.net.usePlainSocketImpl=true. The property can also be configured in the JDK network configuration file, located in ${java.home}/conf/net.properties. The old implementation, and the system property to select the old implementation, will be removed in a future release.

Allow SASL Mechanisms to Be Restricted

A security property named jdk.sasl.disabledMechanisms has been added that can be used to disable SASL mechanisms. Any disabled mechanism will be ignored if it is specified in the mechanisms argument of Sasl.createSaslClient or the mechanism argument of Sasl.createSaslServer. The default value for this security property is empty, which means that no mechanisms are disabled out-of-the-box.

javap Checksum Uses SHA-256

javap includes a checksum of the contents of the class file in verbose output. The checksum is now calculated with the SHA-256 algorithm, instead of the older MD5 algorithm.

New Japanese Era Name: Reiwa

An instance representing the new Reiwa era has been added to this update. Unlike other eras, there is no public field for this era. It can be obtained by calling JapaneseEra.of(3) or JapaneseEra.valueOf("Reiwa"). JDK 13 and later will have a new public field to represent this era.

The placeholder name, "NewEra", for the Japanese era that started from May 1st, 2019 has been replaced with the new official name. Applications that relied on the placeholder name (see JDK-8202088) to obtain the new era singleton (JapaneseEra.valueOf("NewEra")) will no longer work.

Upgraded CLDR to Version 35.1

Locale data based on Unicode Consortium's CLDR has been upgraded to their version 35.1, which includes several localized display names for the Japanese new era, Reiwa. There are some notable locale data changes, such as year formatting in Dutch locale (JDK-8225240) and French grouping separator change (JDK-8225245). For the detailed locale data changes, please refer to the cumulative CLDR changes from the previously supported version v.33. The following are links to each CLDR upgrade release: - CLDR 33.1: http://cldr.unicode.org/index/downloads/cldr-33-1 - CLDR 34: http://cldr.unicode.org/index/downloads/cldr-34 - CLDR 35, 35.1: http://cldr.unicode.org/index/downloads/cldr-35

Support for Unicode 12.1

This release upgrades Unicode support to 12.1 which includes the following: - java.lang.Character supports Unicode Character Database of 12.1 level, in which 12.0 adds 554 characters since 11.0, for a total of 137,928 characters. These additions include 4 new scripts, for a total of 150 scripts, as well as 61 new emoji characters. 12.1 adds exactly one character, U+32FF SQUARE ERA NAME REIWA, since 12.0. - java.text.Bidi and java.text.Normalizer classes support 12.0 level of Unicode Standard Annexes, #9 and #15, respectively. - java.util.regex package supports Extended Grapheme Clusters based on 12.0 level of Unicode Standard Annex #29

Removal of Runtime Trace Methods

The obsolete methods traceInstructions(boolean) and traceMethodCalls(boolean) have been removed from the java.lang.Runtime class. These methods have been non-functional for many releases, and their intended functions are provided by the Java Virtual Machine Tool Interface (JVMTI).

StringBuffer(CharSequence) and StringBuilder(CharSequence) Throw NegativeArraySizeException for Negatively Sized Argument

The behavior of StringBuffer(CharSequence) and StringBuilder(CharSequence) is changed for the argument reporting a negative length. The constructors were inconsistently throwing either NegativeArraySizeException or IndexOutOfBoundException. The new behavior is to always throw NegativeArraySizeException for any argument reporting a negative length.

Default Process launch mechanism on Linux now uses posix_spawn

Runtime.exec() and ProcessBuilder, on Linux now use posix_spawn(3) to spawn child processes. This increases reliability and performance in low-memory situations.

GraphicsEnvironment.getCenterPoint() and getMaximumWindowBounds() are Unified Across Platforms

Two methods were added to the GraphicsEnvironment class in JDK 1.4: - getCenterPoint() - getMaximumWindowBounds()

See https://docs.oracle.com/javase/7/docs/technotes/guides/awt/1.4/AWTChanges.html#windowCentering.

The page in the preceding link includes the following description:

"X-Window, Xinerama All monitors share a single virtual coordinate space, as on Microsoft Windows. However, it is possible for the user to specify through X resources where windows should be centered. If these resources are set, getCenterPoint reflects their value. Otherwise, it returns the point at the center of the virtual coordinate space. (In practice, this will almost always be set - CDE sets it by default.)"

Now, in JDK 13, the implementation of getCenterPoint() and getMaximumWindowBounds() has been unified across the platforms (Windows, Linux, Solaris, and macOS): - getCenterPoint returns the coordinates of the center of the primary display, for all platforms. - getMaximumWindowBounds returns the bounds of the primary display minus display insets, for all platforms.

SunPKCS11 Provider Upgraded with Support for PKCS#11 v2.40

The SunPKCS11 provider has been updated with support for PKCS#11 v2.40. This version adds support for more algorithms such as the AES/GCM/NoPadding cipher, DSA signatures using SHA-2 family of message digests, and RSASSA-PSS signatures when the corresponding PKCS11 mechanisms are supported by the underlying PKCS11 library.

Memory Growth Issue in SunPKCS11 Fixed

A memory growth issue in the SunPKCS11 cryptographic provider that affects the NSS back-end has been fixed.

A system property, sun.security.pkcs11.disableKeyExtraction has been introduced to disable the fix. A "true" value disables the fix, while a "false" value (default) keeps it enabled.

When enabled, PKCS#11 attributes of the NSS native keys are copied to Java byte buffers after key creation. Once used, NSS keys are destroyed and native heap space is freed up. If NSS keys are required again, they are recreated with the previously saved attributes.

Further information and implementation details can be found in the CSR: JDK-8213430

Added a Default Native GSS-API Library on Windows

A native GSS-API library named sspi_bridge.dll has been added to the JDK on the Windows platform. The library is client-side only and uses the default credentials. It will be loaded when the sun.security.jgss.native system property is set to "true". A user can still load a third-party native GSS-API library by setting the sun.security.jgss.lib system property to the appropriate path.

Native GSS automatically uses cached credentials from operating systems, thus the javax.security.auth.useSubjectCredsOnly system property should be set to false.

com.sun.security.auth.module.Krb5LoginModule does not call native JGSS. Avoid using com.sun.security.auth.module.Krb5LoginModule from JAAS config.

JEP 378: Text Blocks

Summary

Add text blocks to the Java language. A text block is a multi-line string literal that avoids the need for most escape sequences, automatically formats the string in a predictable way, and gives the developer control over the format when desired.

History

Text blocks were proposed by JEP 355 in early 2019 as a follow-on to explorations begun in JEP 326 (Raw String Literals), which was initially targeted to JDK 12 but eventually withdrawn and did not appear in that release. JEP 355 was targeted to JDK 13 in June 2019 as a preview feature. Feedback on JDK 13 suggested that text blocks should be previewed again in JDK 14, with the addition of two new escape sequences. Consequently, JEP 368 was targeted to JDK 14 in November 2019 as a preview feature. Feedback on JDK 14 suggested that text blocks were ready to become final and permanent in JDK 15 with no further changes.

Goals

• Simplify the task of writing Java programs by making it easy to express strings that span several lines of source code, while avoiding escape sequences in common cases.

• Enhance the readability of strings in Java programs that denote code written in non-Java languages.

• Support migration from string literals by stipulating that any new construct can express the same set of strings as a string literal, interpret the same escape sequences, and be manipulated in the same ways as a string literal.

• Add escape sequences for managing explicit white space and newline control.

Non-Goals

• It is not a goal to define a new reference type, distinct from java.lang.String, for the strings expressed by any new construct.

• It is not a goal to define new operators, distinct from +, that take String operands.

• Text blocks do not directly support string interpolation. Interpolation may be considered in a future JEP. In the meantime, the new instance method String::formatted aids in situations where interpolation might be desired.

• Text blocks do not support raw strings, that is, strings whose characters are not processed in any way.

Motivation

In Java, embedding a snippet of HTML, XML, SQL, or JSON in a string literal "..." usually requires significant editing with escapes and concatenation before the code containing the snippet will compile. The snippet is often difficult to read and arduous to maintain.

More generally, the need to denote short, medium, and long blocks of text in a Java program is near universal, whether the text is code from other programming languages, structured text representing golden files, or messages in natural languages. On the one hand, the Java language recognizes this need by allowing strings of unbounded size and content; on the other hand, it embodies a design default that strings should be small enough to denote on a single line of a source file (surrounded by " characters), and simple enough to escape easily. This design default is at odds with the large number of Java programs where strings are too long to fit comfortably on a single line.

Accordingly, it would improve both the readability and the writability of a broad class of Java programs to have a linguistic mechanism for denoting strings more literally than a string literal -- across multiple lines and without the visual clutter of escapes. In essence, a two-dimensional block of text, rather than a one-dimensional sequence of characters.

Still, it is impossible to predict the role of every string in Java programs. Just because a string spans multiple lines of source code does not mean that newline characters are desirable in the string. One part of a program may be more readable when strings are laid out over multiple lines, but the embedded newline characters may change the behavior of another part of the program. Accordingly, it would be helpful if the developer had precise control over where newlines appear, and, as a related matter, how much white space appears to the left and right of the "block" of text.

HTML example

Using "one-dimensional" string literals

` String html = "<html>\n" + " <body>\n" + " <p>Hello, world</p>\n" + " </body>\n" + "</html>\n"; `

Using a "two-dimensional" block of text

` String html = """ <html> <body> <p>Hello, world</p> </body> </html> """; `

SQL example

Using "one-dimensional" string literals

` String query = "SELECT \"EMP_ID\", \"LAST_NAME\" FROM \"EMPLOYEE_TB\"\n" + "WHERE \"CITY\" = 'INDIANAPOLIS'\n" + "ORDER BY \"EMP_ID\", \"LAST_NAME\";\n"; `

Using a "two-dimensional" block of text

` String query = """ SELECT "EMP_ID", "LAST_NAME" FROM "EMPLOYEE_TB" WHERE "CITY" = 'INDIANAPOLIS' ORDER BY "EMP_ID", "LAST_NAME"; """; `

Polyglot language example

Using "one-dimensional" string literals

` ScriptEngine engine = new ScriptEngineManager().getEngineByName("js"); Object obj = engine.eval("function hello() {\n" + " print('\"Hello, world\"');\n" + "}\n" + "\n" + "hello();\n"); `

Using a "two-dimensional" block of text

``` ScriptEngine engine = new ScriptEngineManager().getEngineByName("js"); Object obj = engine.eval(""" function hello() { print('"Hello, world"'); }

                     hello();
                     """);

```

Description

This section is identical to the same section in this JEP's predecessor, JEP 355, except for the addition of the subsection on new escape sequences.

A text block is a new kind of literal in the Java language. It may be used to denote a string anywhere that a string literal could appear, but offers greater expressiveness and less accidental complexity.

A text block consists of zero or more content characters, enclosed by opening and closing delimiters.

The opening delimiter is a sequence of three double quote characters (""") followed by zero or more white spaces followed by a line terminator. The content begins at the first character after the line terminator of the opening delimiter.

The closing delimiter is a sequence of three double quote characters. The content ends at the last character before the first double quote of the closing delimiter.

The content may include double quote characters directly, unlike the characters in a string literal. The use of \" in a text block is permitted, but not necessary or recommended. Fat delimiters (""") were chosen so that " characters could appear unescaped, and also to visually distinguish a text block from a string literal.

The content may include line terminators directly, unlike the characters in a string literal. The use of \n in a text block is permitted, but not necessary or recommended. For example, the text block:

` """ line 1 line 2 line 3 """ `

is equivalent to the string literal:

` "line 1\nline 2\nline 3\n" `

or a concatenation of string literals:

` "line 1\n" + "line 2\n" + "line 3\n" `

If a line terminator is not required at the end of the string, then the closing delimiter can be placed on the last line of content. For example, the text block:

` """ line 1 line 2 line 3""" `

is equivalent to the string literal:

` "line 1\nline 2\nline 3" `

A text block can denote the empty string, although this is not recommended because it needs two lines of source code:

` String empty = """ """; `

Here are some examples of ill-formed text blocks:

` String a = """"""; // no line terminator after opening delimiter String b = """ """; // no line terminator after opening delimiter String c = """ "; // no closing delimiter (text block continues to EOF) String d = """ abc \ def """; // unescaped backslash (see below for escape processing) `

Compile-time processing

A text block is a constant expression of type String, just like a string literal. However, unlike a string literal, the content of a text block is processed by the Java compiler in three distinct steps:

1. Line terminators in the content are translated to LF (\u000A). The purpose of this translation is to follow the principle of least surprise when moving Java source code across platforms.

2. Incidental white space surrounding the content, introduced to match the indentation of Java source code, is removed.

3. Escape sequences in the content are interpreted. Performing interpretation as the final step means developers can write escape sequences such as \n without them being modified or deleted by earlier steps.

The processed content is recorded in the class file as a CONSTANT_String_info entry in the constant pool, just like the characters of a string literal. The class file does not record whether a CONSTANT_String_info entry was derived from a text block or a string literal.

At run time, a text block is evaluated to an instance of String, just like a string literal. Instances of String that are derived from text blocks are indistinguishable from instances derived from string literals. Two text blocks with the same processed content will refer to the same instance of String due to interning, just like for string literals.

The following sections discuss compile-time processing in more detail.

1. Line terminators

Line terminators in the content are normalized from CR (\u000D) and CRLF (\u000D\u000A) to LF (\u000A) by the Java compiler. This ensures that the string derived from the content is equivalent across platforms, even if the source code has been translated to a platform encoding (see javac -encoding).

For example, if Java source code that was created on a Unix platform (where the line terminator is LF) is edited on a Windows platform (where the line terminator is CRLF), then without normalization, the content would become one character longer for each line. Any algorithm that relied on LF being the line terminator might fail, and any test that needed to verify string equality with String::equals would fail.

The escape sequences \n (LF), \f (FF), and \r (CR) are not interpreted during normalization; escape processing happens later.

2. Incidental white space

The text blocks shown above were easier to read than their concatenated string literal counterparts, but the obvious interpretation for the content of a text block would include the spaces added to indent the embedded string so that it lines up neatly with the opening delimiter. Here is the HTML example using dots to visualize the spaces that the developer added for indentation:

` String html = """ ..............<html> .............. <body> .............. <p>Hello, world</p> .............. </body> ..............</html> .............."""; `

Since the opening delimiter is generally positioned to appear on the same line as the statement or expression which consumes the text block, there is no real significance to the fact that 14 visualized spaces start each line. Including those spaces in the content would mean the text block denotes a string different from the one denoted by the concatenated string literals. This would hurt migration, and be a recurring source of surprise: it is overwhelmingly likely that the developer does not want those spaces in the string. Also, the closing delimiter is generally positioned to align with the content, which further suggests that the 14 visualized spaces are insignificant.

Spaces may also appear at the end of each line, especially when a text block is populated by copy-pasting snippets from other files (which may themselves have been formed by copy-pasting from yet more files). Here is the HTML example reimagined with some trailing white space, again using dots to visualize spaces:

` String html = """ ..............<html>... .............. <body> .............. <p>Hello, world</p>.... .............. </body>. ..............</html>... .............."""; `

Trailing white space is most often unintentional, idiosyncratic, and insignificant. It is overwhelmingly likely that the developer does not care about it. Trailing white space characters are similar to line terminators, in that both are invisible artifacts of the source code editing environment. With no visual guide to the presence of trailing white space characters, including them in the content would be a recurring source of surprise, as it would affect the length, hash code, etc, of the string.

Accordingly, an appropriate interpretation for the content of a text block is to differentiate incidental white space at the start and end of each line, from essential white space. The Java compiler processes the content by removing incidental white space to yield what the developer intended. String::indent can then be used to further manipulate indentation if desired. Using | to visualize margins:

` |<html>| | <body>| | <p>Hello, world</p>| | </body>| |</html>| `

The re-indentation algorithm takes the content of a text block whose line terminators have been normalized to LF. It removes the same amount of white space from each line of content until at least one of the lines has a non-white space character in the leftmost position. The position of the opening """ characters has no effect on the algorithm, but the position of the closing """ characters does have an effect if placed on its own line. The algorithm is as follows:

1. Split the content of the text block at every LF, producing a list of individual lines. Note that any line in the content which was just an LF will become an empty line in the list of individual lines.

2. Add all non-blank lines from the list of individual lines into a set of determining lines. (Blank lines -- lines that are empty or are composed wholly of white space -- have no visible influence on the indentation. Excluding blank lines from the set of determining lines avoids throwing off step 4 of the algorithm.)

3. If the last line in the list of individual lines (i.e., the line with the closing delimiter) is blank, then add it to the set of determining lines. (The indentation of the closing delimiter should influence the indentation of the content as a whole -- a significant trailing line policy.)

4. Compute the common white space prefix of the set of determining lines, by counting the number of leading white space characters on each line and taking the minimum count.

5. Remove the common white space prefix from each non-blank line in the list of individual lines.

6. Remove all trailing white space from all lines in the modified list of individual lines from step 5. This step collapses wholly-white-space lines in the modified list so that they are empty, but does not discard them.

7. Construct the result string by joining all the lines in the modified list of individual lines from step 6, using LF as the separator between lines. If the final line in the list from step 6 is empty, then the joining LF from the previous line will be the last character in the result string.

The escape sequences \b (backspace), \t (tab) and \s (space) are not interpreted by the algorithm; escape processing happens later. Similarly, the \<line-terminator> escape sequence does not prevent the splitting of lines on the line-terminator since the sequence is treated as two separate characters until escape processing.

The re-indentation algorithm will be normative in The Java Language Specification. Developers will have access to it via String::stripIndent, a new instance method.

Significant trailing line policy

Normally, one would format a text block in two ways: first, position the left edge of the content to appear under the first " of the opening delimiter, and second, place the closing delimiter on its own line to appear exactly under the opening delimiter. The resulting string will have no white space at the start of any line, and will not include the trailing blank line of the closing delimiter.

However, because the trailing blank line is considered a determining line, moving it to the left has the effect of reducing the common white space prefix, and therefore reducing the the amount of white space that is stripped from the start of every line. In the extreme case, where the closing delimiter is moved all the way to the left, that reduces the common white space prefix to zero, effectively opting out of white space stripping.

For example, with the closing delimiter moved all the way to the left, there is no incidental white space to visualize with dots:

` String html = """ <html> <body> <p>Hello, world</p> </body> </html> """; `

Including the trailing blank line with the closing delimiter, the common white space prefix is zero, so zero white space is removed from the start of each line. The algorithm thus produces: (using | to visualize the left margin)

` | <html> | <body> | <p>Hello, world</p> | </body> | </html> `

Alternatively, suppose the closing delimiter is not moved all the way to the left, but rather under the t of html so it is eight spaces deeper than the variable declaration:

` String html = """ <html> <body> <p>Hello, world</p> </body> </html> """; `

The spaces visualized with dots are considered to be incidental:

` String html = """ ........ <html> ........ <body> ........ <p>Hello, world</p> ........ </body> ........ </html> ........"""; `

Including the trailing blank line with the closing delimiter, the common white space prefix is eight, so eight white spaces are removed from the start of each line. The algorithm thus preserves the essential indentation of the content relative to the closing delimiter:

` | <html> | <body> | <p>Hello, world</p> | </body> | </html> `

Finally, suppose the closing delimiter is moved slightly to the right of the content:

` String html = """ <html> <body> <p>Hello, world</p> </body> </html> """; `

The spaces visualized with dots are considered to be incidental:

` String html = """ ..............<html> .............. <body> .............. <p>Hello, world</p> .............. </body> ..............</html> .............. """; `

The common white space prefix is 14, so 14 white spaces are removed from the start of each line. The trailing blank line is stripped to leave an empty line, which being the last line is then discarded. In other words, moving the closing delimiter to the right of the content has no effect, and the algorithm again preserves the essential indentation of the content:

` |<html> | <body> | <p>Hello, world</p> | </body> |</html> `

3. Escape sequences

After the content is re-indented, any escape sequences in the content are interpreted. Text blocks support all of the escape sequences supported in string literals, including \n, \t, \', \", and \\. See section 3.10.6 of the The Java Language Specification for the full list. Developers will have access to escape processing via String::translateEscapes, a new instance method.

Interpreting escapes as the final step allows developers to use \n, \f, and \r for vertical formatting of a string without it affecting the translation of line terminators in step 1, and to use \b and \t for horizontal formatting of a string without it affecting the removal of incidental white space in step 2. For example, consider this text block that contains the \r escape sequence (CR):

` String html = """ <html>\r <body>\r <p>Hello, world</p>\r </body>\r </html>\r """; `

The CR escapes are not processed until after the line terminators have been normalized to LF. Using Unicode escapes to visualize LF (\u000A) and CR (\u000D), the result is:

` |<html>\u000D\u000A | <body>\u000D\u000A | <p>Hello, world</p>\u000D\u000A | </body>\u000D\u000A |</html>\u000D\u000A `

Note that it is legal to use " and "" freely inside a text block, except immediately before the closing delimiter. For example, the following text blocks are legal:

``` String story = """ "When I use a word," Humpty Dumpty said, in rather a scornful tone, "it means just what I choose it to mean - neither more nor less." "The question is," said Alice, "whether you can make words mean so many different things." "The question is," said Humpty Dumpty, "which is to be master - that's all." """; // Note the newline before the closing delimiter

String code = """ String empty = ""; """; ```

However, a sequence of three " characters requires at least one " to be escaped, in order to avoid mimicking the closing delimiter. (A sequence of n " characters requires at least Math.floorDiv(n,3) of them to be escaped.) The use of " immediately before the closing delimiter also requires escaping. For example:

``` String code = """ String text = """ A text block inside a text block """; """;

String tutorial1 = """ A common character in Java programs is """";

String tutorial2 = """ The empty string literal is formed from " characters as follows: """"";

System.out.println(""" 1 " 2 "" 3 """ 4 """" 5 """"" 6 """""" 7 """"""" 8 """""""" 9 """"""""" 10 """""""""" 11 """"""""""" 12 """""""""""" """); ```

New escape sequences

To allow finer control of the processing of newlines and white space, we introduce two new escape sequences.

First, the \<line-terminator> escape sequence explicitly suppresses the insertion of a newline character.

For example, it is common practice to split very long string literals into concatenations of smaller substrings, and then hard wrap the resulting string expression onto multiple lines:

String literal = "Lorem ipsum dolor sit amet, consectetur adipiscing " +
                 "elit, sed do eiusmod tempor incididunt ut labore " +
                 "et dolore magna aliqua.";

With the \<line-terminator> escape sequence this could be expressed as:

  String text = """
                Lorem ipsum dolor sit amet, consectetur adipiscing \
                elit, sed do eiusmod tempor incididunt ut labore \
                et dolore magna aliqua.\
                """;

For the simple reason that character literals and traditional string literals don't allow embedded newlines, the \<line-terminator> escape sequence is only applicable to text blocks.

Second, the new \s escape sequence simply translates to a single space (\u0020).

Escape sequences aren't translated until after incidental space stripping, so \s can act as fence to prevent the stripping of trailing white space. Using \s at the end of each line in this example guarantees that each line is exactly six characters long:

String colors = """
    red  \s
    green\s
    blue \s
    """;

The \s escape sequence can be used in text blocks, traditional string literals, and character literals.

Concatenation of text blocks

Text blocks can be used anywhere a string literal can be used. For example, text blocks and string literals may be concatenated interchangeably:

` String code = "public void print(Object o) {" + """ System.out.println(Objects.toString(o)); } """; `

However, concatenation involving a text block can become rather clunky. Take this text block as a starting point:

` String code = """ public void print(Object o) { System.out.println(Objects.toString(o)); } """; `

Suppose it needs to be changed so that the type of o comes from a variable. Using concatenation, the text block that contains the trailing code will need to start on a new line. Unfortunately, the straightforward insertion of a newline in the program, as below, will cause a long span of white space between the type and the text beginning o :

` String code = """ public void print(""" + type + """ o) { System.out.println(Objects.toString(o)); } """; `

The white space can be removed manually, but this hurts readability of the quoted code:

` String code = """ public void print(""" + type + """ o) { System.out.println(Objects.toString(o)); } """; `

A cleaner alternative is to use String::replace or String::format, as follows:

` String code = """ public void print($type o) { System.out.println(Objects.toString(o)); } """.replace("$type", type); `

` String code = String.format(""" public void print(%s o) { System.out.println(Objects.toString(o)); } """, type); `

Another alternative involves the introduction of a new instance method, String::formatted, which could be used as follows:

` String source = """ public void print(%s object) { System.out.println(Objects.toString(object)); } """.formatted(type); `

Additional Methods

The following methods will be added to support text blocks;

• String::stripIndent(): used to strip away incidental white space from the text block content
• String::translateEscapes(): used to translate escape sequences
• String::formatted(Object... args): simplify value substitution in the text block

Alternatives

Do nothing

Java has prospered for over 20 years with string literals that required newlines to be escaped. IDEs ease the maintenance burden by supporting automatic formatting and concatenation of strings that span several lines of source code. The String class has also evolved to include methods that simplify the processing and formatting of long strings, such as a method that presents a string as a stream of lines. However, strings are such a fundamental part of the Java language that the shortcomings of string literals are apparent to vast numbers of developers. Other JVM languages have also made advances in how long and complex strings are denoted. Unsurprisingly, then, multi-line string literals have consistently been one of the most requested features for Java. Introducing a multi-line construct of low to moderate complexity would have a high payoff.

Allow a string literal to span multiple lines

Multi-line string literals could be introduced in Java simply by allowing line terminators in existing string literals. However, this would do nothing about the pain of escaping " characters. \" is the most frequently occurring escape sequence after \n, because of frequency of code snippets. The only way to avoid escaping " in a string literal would be to provide an alternate delimiter scheme for string literals. Delimiters were much discussed for JEP 326 (Raw String Literals), and the lessons learned were used to inform the design of text blocks, so it would be misguided to upset the stability of string literals.

Adopt another language's multi-string literal

According to Brian Goetz:

Many people have suggested that Java should adopt multi-line string literals from Swift or Rust. However, the approach of “just do what language X does” is intrinsically irresponsible; nearly every feature of every language is conditioned by other features of that language. Instead, the game is to learn from how other languages do things, assess the tradeoffs they’ve chosen (explicitly and implicitly), and ask what can be applied to the constraints of the language we have and user expectations within the community we have.

For JEP 326 (Raw String Literals), we surveyed many modern programming languages and their support for multi-line string literals. The results of these surveys influenced the current proposal, such as the choice of three " characters for delimiters (although there were other reasons for this choice too) and the recognition of the need for automatic indentation management.

Do not remove incidental white space

If Java introduced multi-line string literals without support for automatically removing incidental white space, then many developers would write a method to remove it themselves, or lobby for the String class to include a removal method. However, that implies a potentially expensive computation every time the string is instantiated at run time, which would reduce the benefit of string interning. Having the Java language mandate the removal of incidental white space, both in leading and trailing positions, seems the most appropriate solution. Developers can opt out of leading white space removal by careful placement of the closing delimiter.

Raw string literals

For JEP 326 (Raw String Literals), we took a different approach to the problem of denoting strings without escaping newlines and quotes, focusing on the raw-ness of strings. We now believe that this focus was wrong, because while raw string literals could easily span multiple lines of source code, the cost of supporting unescaped delimiters in their content was extreme. This limited the effectiveness of the feature in the multi-line use case, which is a critical one because of the frequency of embedding multi-line (but not truly raw) code snippets in Java programs. A good outcome of the pivot from raw-ness to multi-line-ness was a renewed focus on having a consistent escape language between string literals, text blocks, and related features that may be added in future.

Testing

Tests that use string literals for the creation, interning, and manipulation of instances of String should be duplicated to use text blocks too. Negative tests should be added for corner cases involving line terminators and EOF.

Tests should be added to ensure that text blocks can embed Java-in-Java, Markdown-in-Java, SQL-in-Java, and at least one JVM-language-in-Java.

JEP 354: Switch Expressions (Preview)

Extend switch so it can be used as either a statement or an expression, and so that both forms can use either traditional case ... : labels (with fall through) or new case ... -> labels (with no fall through), with a further new statement for yielding a value from a switch expression. These changes will simplify everyday coding, and prepare the way for the use of pattern matching in switch. This is a preview language feature in JDK 13.

Corrected UnicodeDecoder U+FFFE Handling

The behavior of decoding the code point U+FFFE in the middle of the buffer has been corrected for StandardCharsets.UTF_16[LE/BE]. The decoders have been reporting the code point as "malformed". They now pass through the code point in order to conform to the Unicode Consortium's Corrigendum#9.

Removal of VM option -XX:+AggressiveOpts

The VM option -XX:+AggressiveOpts was deprecated in JDK 11 and support for it was removed in JDK 12 (where its use was ignored other than generating a warning). Use of this flag will now cause an error on VM initialization.

JEP 350 Dynamic CDS Archiving

JEP 350 extends application class-data sharing (AppCDS) to allow the dynamic archiving of classes as a Java application is exiting. It also improves the usability of AppCDS by eliminating the need for users to do trial runs to create a class list for each application. The existing static archiving enabled by the -Xshare:dump option, using a class list, continues work as is.

The dynamically-generated archive is created on top of the default system archive packaged with the running JDK image. A separate top-layer archive file is generated for each application. The user can specify the filename of the dynamic archive name as the argument to the -XX:ArchiveClassesAtExit option. For example, the following command creates hello.jsa: ` % bin/java -XX:ArchiveClassesAtExit=hello.jsa -cp hello.jar Hello To run the same application using this dynamic archive: `` % bin/java -XX:SharedArchiveFile=hello.jsa -cp hello.jar Hello ```

The user could also specify both the base and the dynamic archives in the -XX:SharedArchiveFile option such as: ` -XX:SharedArchiveFile=<base archive>:<dynamic archive> `

CSR JDK-8221706 has more details on the command line option.

Deprecated Java Options -Xverify:none and -noverify

The Java options -Xverify:none and -noverify have been deprecated in this release. The options will continue to work as intended but will generate the following warning when used:

 warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be removed in a future release. 

Deprecating these options helps prevent users from running code that violates the JVM Specification, which can leave their applications open to malicious code.

Users who need to run without startup verification can use AppCDS to archive their classes. The classes are verified during archiving and avoid verification at runtime.

Note that if you encounter issues while using either of these options, it is very likely that you will be required to reproduce the problem without using these options before Oracle Support can assist with an investigation.

Deprecated Java Options -Xverify:none and -noverify

The Java options -Xverify:none and -noverify have been deprecated in this release. The options will continue to work as intended but will generate the following warning when used:

 warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be removed in a future release.

Deprecating these options helps prevent users from running code that violates the JVM Specification, which can leave their applications open to malicious code.

Users who need to run without startup verification can use AppCDS to archive their classes. The classes are verified during archiving and avoid verification at runtime.

NullPointerException in java.util.logging.Handler#isLoggable

The default implementation of java.util.logging.Handler.isLoggable has been updated to match its specification and to return false if the record parameter is null. The implementation of java.util.logging.MemoryHandler.isLoggable and java.util.logging.MemoryHandler.publish will no longer throw NullPointerException if the record parameter is null, which conforms to their specification.

New keytool -showinfo -tls Command for Displaying TLS Configuration Information

A new keytool -showinfo -tls command has been added that displays TLS configuration information.

Removal of Two Comodo Root CA Certificates

Two Comodo root CA certificates have expired and were removed from the cacerts keystore: + alias name "utnuserfirstclientauthemailca [jdk]"

Distinguished Name: CN=UTN-USERFirst-Client Authentication and Email, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US

• alias name "utnuserfirsthardwareca [jdk]"

  Distinguished Name: CN=UTN-USERFirst-Hardware, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US

Configurable Read Timeout for CRLs

The com.sun.security.crl.readtimeout system property sets the maximum read timeout for CRL retrievals, in seconds. If the property has not been set, or if its value is negative, it is set to the default value of 15 seconds. A value of 0 means an infinite timeout.

Support for MS Cryptography Next Generation (CNG)

The SunMSCAPI provider now supports reading private keys in Cryptography Next Generation (CNG) format. This means that RSA and EC keys in CNG format are loadable from Windows keystores, such as "Windows-MY". Signature algorithms related to EC (SHA1withECDSA, SHA256withECDSA, etc.) are also supported.

Removal of Two DocuSign Root CA Certificates

Two DocuSign root CA certificates have expired and were removed from the cacerts keystore: + alias name "certplusclass2primaryca [jdk]"

Distinguished Name: CN=Class 2 Primary CA, O=Certplus, C=FR

• alias name "certplusclass3pprimaryca [jdk]"

  Distinguished Name: CN=Class 3P Primary CA, O=Certplus, C=FR

Removal of T-Systems Deutsche Telekom Root CA 2 Certificate

The T-Systems Deutsche Telekom Root CA 2 certificate has expired and was removed from the cacerts keystore: + alias name "deutschetelekomrootca2 [jdk]"

Distinguished Name: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche Telekom AG, C=DE

DateTimeFormatter now throws DateTimeParseException on Invalid HOUR_OF_AMPM

The parsing behavior of DateTimeFormatter with HOUR_OF_AMPM has changed. It now correctly throws a DateTimeParseException with an out-of-bounds input values, such as 12.

New Methods for Creating DOM and SAX Factories with Namespace Support

New methods have been added for instantiating DOM and SAX factories with Namespace support by default. These methods are prefixed over their existing counterparts with "NS," which stands for NamespaceAware. Below is a list of the new methods:

• newDefaultNSInstance()
• newNSInstance()
• newNSInstance(String factoryClassName, ClassLoader classLoader)

Using these new methods, a parser created through the factory will be NamespaceAware by default. For example, the following statement:

DocumentBuilder db = DocumentBuilderFactory.newDefaultNSInstance().newDocumentBuilder(); 

is equivalent to:

DocumentBuilderFactory dbf = DocumentBuilderFactory.newDefaultInstance(); 
dbf.setNamespaceAware(true); 
DocumentBuilder db = dbf.newDocumentBuilder(); 

Support for Kerberos Cross-Realm Referrals (RFC 6806)

The Kerberos client has been enhanced with the support of principal name canonicalization and cross-realm referrals, as defined by the RFC 6806 protocol extension.

As a result of this new feature, the Kerberos client can take advantage of more dynamic environment configurations and does not necessarily need to know (in advance) how to reach the realm of a target principal (user or service).

Support is enabled by default and 5 is the maximum number of referral hops allowed. To turn it off, set the sun.security.krb5.disableReferrals security or system property to false. To configure a custom maximum number of referral hops, set the sun.security.krb5.maxReferrals security or system property to any positive value.

See further information in JDK-8223172.

Lookup.unreflectSetter(Field) Now Throws IllegalAccessException for Static Final Fields

java.lang.invoke.MethodHandles.Lookup::unreflectSetter returns a MethodHandle giving write access to the given Field object. A Field object for a static final field does not have write access even if its accessible flag is true (i.e. Field.setAccessibe(true) has been called). In JDK 13, Lookup::unreflectSetter is fixed to throw IllegalAccessException if the given Field object is a static final field.

New String Constants for Canonical XML 1.1 URIs

New String constants named INCLUSIVE_11 and INCLUSIVE_11_WITH_COMMENTS have been added to the javax.xml.crypto.dsig.CanonicalizationMethod API. These represent the URIs for the Canonical XML 1.1 and Canonical XML 1.1 with Comments algorithms for XML Signature.

[xmldsig] Added KeyValue::EC_TYPE

The ECKeyValue type as described in the W3C Recommendation for XML-Signature Syntax and Processing is now supported. A new EC_TYPE constant has been added to the javax.xml.crypto.dsig.keyinfo.KeyValue interface. Please note that only the NamedCurve domain parameter type is currently supported, and the ECParameters explicit curve parameter type is not supported.

Updated XML Signature Implementation to Apache Santuario 2.1.3

The XML Signature implementation in the java.xml.crypto module has been updated to version 2.1.3 of Apache Santuario. New features include: * Added support for embedding elliptic curve public keys in the KeyValue element

com.sun.org.apache.xml.internal.security.ignoreLineBreaks System Property

An Apache Santuario library version upgrade, used by the javax.xml.crypto.* packages, introduces a behavioral change where a new Base64 encoder uses "\r\n" as end-of-line terminator. By default, XML signatures signed using API calls form the javax.xml.crypto.dsig package includes the escaped '\r' character, encoded as " " or " ".

A new com.sun.org.apache.xml.internal.security.ignoreLineBreaks system property may be set to a value of "true" if an application is unable to handle the encoded output data changes where " " or " " get appended to new lines in encoding operations. The effect of this property is to not include the carriage return character in base64-encoded fields in XML signature generated by calls to the javax.xml.crypto.* packages.

Additional information can be found at https://issues.apache.org/jira/browse/SANTUARIO-482.

Improved Handling of the "Class-Path" JAR Manifest Attribute

The JAR file specification has been updated to clarify what constitutes a valid entry for the Class-Path JAR Manifest Attribute. See the JAR file specification for further details.

Invalid entries are now ignored. Applications relying on invalid Class-Path entries may see a ClassNotFoundException. A system property has been added to aid in debugging the Class-Path attribute. When the "jdk.net.URLClassPath.showIgnoredClassPathEntries" property is set to true, invalid Class-Path entries will be printed to the console.

Change DOM Parser to Not Resolve EntityReference and Add Text Node with DocumentBuilderFactory.setExpandEntityReferences(false)

The implementation of the ExpandEntityReferences feature was changed to comply with the specification of the DocumentBuilderFactory.setExpandEntityReferences method. Specifically, now when the method is set to false and encounters an entity reference, a DOM parser created by the DocumentBuilderFactory adds the EntityReference node to the DOM tree without the expanded Text node. Before the change, the implementation incorrectly added both nodes.

With the change, the DOM parser no longer reads and resolves entity references when the feature ExpandEntityReferences is set to false. For applications that intend to avoid resolving entity references, it will work as expected.

This change also affects the DOM Load and Save parser. The entities parameter is aligned with the ExpandEntityReferences feature, so that setting the entities parameter to true is equivalent to setting ExpandEntityReferences to false. In the following code snippet, the document will contain EntityReference nodes but not expanded Text nodes: ` LSParser domParser = domImplementationLS.createLSParser(MODE_SYNCHRONOUS, null); domParser.getDomConfig().setParameter("entities", true); LSInput src = domImplementationLS.createLSInput(); src.setStringData(source); Document document = domParser.parse(src); Because the references are not resolved, the resulting string will contain entity references without the text when thedocumentis serialized: `` LSSerializer lsSerializer = domImplementationLS.createLSSerializer(); lsSerializer.getDomConfig().setParameter("format-pretty-print", true); String result = lsSerializer.writeToString(document); ```

Deprecated rmic Tool for Removal

The rmic tool has been deprecated and may be removed from a future release. The rmic tool was used to create static stubs that support the Java Remote Method Protocol (JRMP) used by the Java Remote Method Invocation (RMI) facility. Statically generated stubs are obsolete and were replaced by dynamically generated stubs in Java SE 5.0. Dynamically generated stubs no longer require pregeneration using a tool such as rmic, and they are functionally equivalent to statically generated stubs. RMI applications should be migrated to use dynamically generated RMI stubs by changing the way remote objects are exported. See the class documentation for java.rmi.server.UnicastRemoteObject for further details.

More Registers Available When Running Without Compressed References on x86_64

When running with compressed references on x86_64, one of the CPU registers holds the heap base pointer to be used for references encoding/decoding. This register is not available for register allocation.

Simple implementations before this release made this register unavailable (and thus unused) even if compressed references were disabled. In this release, the implementation was revised to put this unused register back into the available registers pool. Configurations with large heaps and/or -XX:-UseCompressedOops benefit from this improvement.

Updated the Default Enabled Cipher Suites Preference

The preference of the default enabled cipher suites has been changed. The compatibility impact should be minimal. If needed, applications can customize the enabled cipher suites and the preference. For more details, refer to the SunJSSE provider documentation and the JSSE Reference Guide documentation.

Session Resumption without Server-Side State in JSSE

The feature allows for the server-side of JSSE to operate stateless. As described in RFC 50771 for TLS 1.2 and below, and RFC 84462 for TLS 1.3, the TLS server sends internal session information in the form of an encrypted session ticket to a client that supports stateless. That session ticket is presented to the server during the TLS handshake to resume the session. This should improve the performance and memory usage of the TLS server under large workloads as the session cache will seldom be used. With less session information cached, some session information may not be available. This feature is not enabled by default and can be turned on by setting two properties.

Note that invalidated stateless TLS sessions could be resumed in the current implementation. The behavior is not guaranteed to be the same in future releases and updates (see bugid JDK-8229148)

Note that in the current implementation, the return value of SSLSession.getID() is not persistent across resumption for TLS 1.3 and stateless TLS 1.2 connections. This could be an issue if applications rely on the session identifier values. This may change to be consistent a future release (See bugid JDK-8229149)

Two new System properties are added in support of this feature: jdk.tls.client.enableSessionTicketExtension is used on the client side to toggle the Session Ticket Extension on the ClientHello message for TLS 1.2. Property value: "true" sends the extension, "false" does not (default).

jdk.tls.server.enableSessionTicketExtension enables a server to use stateless session tickets if the client supports it. Clients that do not support stateless session tickets will use the cache. Property value: "true" enables stateless, "false" does not (default).

Deprecated javax.security.cert APIs with forRemoval=true

The javax.security.cert API has been deprecated and marked for removal. The classes in this package should no longer be used. The java.security.cert package contains suitable replacements.

Removal of Experimental FIPS 140 Compliant Mode from SunJSSE Provider

The experimental FIPS 140 compliant mode has been removed from the SunJSSE provider.

Legacy applications might have used the experimental mode with one of the following approaches: 1. Updating the java.security file and specifying a crypto provider for the SunJSSE provider (for example, security.provider.4=com.sun.net.ssl.internal.ssl.Provider SunPKCS11-NSS) 2. Using the JDK internal class and creating a provider with a specified crypto provider (for example, new com.sun.net.ssl.internal.ssl.Provider(cryptoProvider);).

Because the SunJSSE provider uses JDK default cryptography providers, applications can configure the security.provider security properties to use the FIPS 140 compliant cryptography providers.

Use Server Cipher Suites Preference by Default

For TLS connections, the cipher suite selection, by default, is updated to use the server cipher suites preference. Applications can configure the behavior by using the SSLParameters.setUseCipherSuitesOrder​() method.

Duplicated RSA Services No Longer Supported by SunJSSE Provider

Support for RSA KeyFactory, RSA KeyPairGenerator, MD2withRSA, MD5withRSA, and SHA1withRSA Signature has been removed from SunJSSE provider.

Since JDK 5, SunRsaSign provider was introduced to support these RSA-related algorithms. The only reason for SunJSSE provider to support these was for backward-compatibility with pre-JDK 5 applications. Removal should only impact applications that explicitly request these RSA services from SunJSSE provider. Applications should remove the hardcoded "SunJSSE" provider name.

Removal of the Internal com.sun.net.ssl package which was only used for Compatibility with Legacy JSSE 1.0 Applications

The internal package com.sun.net.ssl has been removed from the JDK. Prior to Java SE 1.4, when JSSE was shipped as a standalone product, the com.sun.net.ssl APIs were supported, but since Java SE 1.4, the package was deprecated and intended for internal use only. Standard replacement APIs such as HostNameVerifier, KeyManager, and TrustManager have been available in the javax.net.ssl package since Java SE 1.4. Although applications should have transitioned to the standard APIs, this note is a final warning that these non-standard APIs have been removed.

Support for X25519 and X448 in TLS

The named elliptic curve groups x25519 and x448 are now available for JSSE key agreement in TLS versions 1.0 to 1.3, with x25519 being the most preferred of the default enabled named groups. The default ordered list is now:

` x25519, secp256r1, secp384r1, secp521r1, x448, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192 `

The default list can be overridden using the system property jdk.tls.namedGroups.

Use SunJCE Mac in SecretKeyFactory PBKDF2 Implementation

The SunJCE implementation of the PBKDF2 SecretKeyFactory will now exclusively use the SunJCE Mac service for the underlying pseudorandom function (PRF). This fixes an issue where 3rd party JCE providers in rare cases could cause the SunJCE PBKDF2 SecretKeyFactory's underlying pseudorandom function (PRF) to fail on Mac.init().

Added FileSystems.newFileSystem(Path, Map<String, ?>) Method

Three new methods have been added to java.nio.file.FileSystems to make it easier to use file system providers that treat the contents of a file as a file system.

• newFileSystem(Path)
• newFileSystem(Path, Map<String, ?>)
• newFileSystem(Path, Map<String, ?>, ClassLoader)

The addition of newFileSystem(Path, Map<String, ?>) creates a source (but not binary) compatibility issue for code that has been using the existing 2-arg newFileSystem(Path, ClassLoader) and specifying the class loader as null. For example, the following cannot be compiled because the reference to newFileSystem is ambiguous:

FileSystem fs = FileSystems.newFileSystem(path, null);

To avoid the ambiguous reference, this code needs to be modified to cast the second parameter to java.lang.ClassLoader.

JNI NewDirectByteBuffer Creates Direct Buffer That Is java.nio.ByteOrder.BIG_ENDIAN

The Java Native Interface (JNI) specification has been clarified in this release to specify that the NewDirectByteBuffer function creates a direct buffer that is always big-endian (high byte first; java.nio.ByteOrder.BIG_ENDIAN). This aligns the specification with long standing behavior (JDK 1.4, released in 2002) so it does not affect existing code.

Files.createSymbolicLink Can Be Used in "Developer Mode" Without Additional Privileges

On Microsoft Windows, java.nio.file.Files.createSymbolicLink has been changed so that it can now be used to create symbolic links when the process is not elevated but the user is running in "Developer Mode". This may be useful for tools and other development time tasks that need to create symbolic links without requiring additional privileges.

Files.isHidden Returns true for Hidden Directories on Windows

On Microsoft Windows, the java.nio.file.Files.isHidden method has historically ignored the DOS "hidden" attribute on directories. This has been fixed in this release so that isHidden now returns true when invoked to test a directory that has this attribute set.

New java.nio.ByteBuffer Bulk get/put Methods Transfer Bytes Without Regard to Buffer Position

java.nio.ByteBuffer and the other buffer types in java.nio now define absolute bulk get and put methods to transfer contiguous sequences of bytes without regard to or effect on the buffer position.

Removal of awt.toolkit System Property

Historically (up to JDK 1.8), documentation for the java.awt.Toolkit class referred to the "awt.toolkit" system property, which was set to the name of the platform implementation subclass. The documentation of this property was removed in JDK 9 because (1) it was an internal detail not intended to be a supported interface and (2) encapsulation by the module system meant that the class could not be directly manipulated. However, the system property was not removed until now. Applications that previously read this property can still, if necessary, obtain it by instantiating the AWT Toolkit and querying the class name via that instance.

Deprecated and Unsupported Swing Motif Look and Feel on macOS

Swing Motif Look and Feel is unsupported on macOS in JDK 13.

In the source code, Swing Motif Look and Feel is deprecated with the intent to remove it in a future release. Use javax.swing.plaf.metal.MetalLookAndFeel instead.

Removal of Old Features from javadoc Tool

The following four features have been removed from the javadoc tool:

Support for generating API documentation using HTML 4: Support for HTML 5 was added in JDK 9 and has been the default since JDK 11. To generate API documentation that is fully compliant with the HTML 5 specification, developers should ensure that any use of HTML tags in their documentation comments is also compliant with the HTML 5 specification.

Support for the "old" javadoc API: This includes the API (com.sun.javadoc), the old standard doclet (com.sun.tools.doclets.standard), and the old entry point (com.sun.tools.javadoc.Start), all in the jdk.javadoc module. A new API and a new standard doclet were introduced in JDK 9, leveraging other modern modeling API such as javax.lang.model. The javadoc tool can be programmatically invoked using the javax.tools.DocumentationTool API, or (for simple use) java.util.spi.ToolProvider. Users that just use the javadoc tool to generate standard API documentation are not affected.

Support for generating documentation using HTML frames: It has been replaced by the "Search" feature, added in JDK 9, and by improved index files and links within pages.

Support for the --no-module-directories option: This option provided limited support for the organization used for the generated documentation by the javadoc tool in JDK 9 and 10, in which the files for different modules were not grouped into separate directories.

Improved Javadoc Search

The search feature in API documentation generated by Javadoc has been improved. You can now consistently search API documentation using partial terms and camel-case abbreviations. See https://docs.oracle.com/en/java/javase/14/docs/specs/javadoc/javadoc-search-spec.html for a full description of search features.

GTK+ 3.20 and Later Unsupported by Swing

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

GTK+ 3.20 and Later Unsupported by Swing

Due to incompatible changes in the GTK+ 3 library versions 3.20 and later, the Swing GTK Look and Feel does not render some UI components when using this library. Therefore Linux installations with versions of GTK+ 3.20 and above are not supported for use by the Swing GTK Look And Feel in this release.

GTK+ 3.20 and Later Unsupported by Swing

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

GTK+ 3.20 and Later Unsupported by Swing

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

GTK+ 3.20 and Later Unsupported by Swing

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

GTK+ 3.20 and Later Unsupported by Swing

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

GTK+ 3.20 and Later Unsupported by Swing

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

Shenandoah Support for Solaris x86_64

Shenandoah is designed to be OS agnostic. However, minor differences in accepted language features in OS-specific tool chains can prevent it from being buildable on some operating systems. This release includes a change that enables Shenandoah builds with Solaris Studio, the default tool chain for the Solaris operating system. Testing shows that, after this change is applied, Shenandoah is fully operational on Solaris 11.

JFR events for Shenandoah

This release implements two JFR events ShenandoahHeapRegionStateChange and ShenandoahHeapRegionInformation which provide internal GC diagnostic data that can be used to visualize the shenandoah heap regions.

ZGC: Maximum Heap Size Increased to 16TB

The maximum supported heap size for ZGC was increased from 4TB to 16TB.

Load reference barriers for Shenandoah

Shenandoah used to employ the weak to-space invariant: allow reads to be done from the collection set while it is being evacuated, and evacuate objects on writes to them. This forced the implementation to have simple read barriers before every read accesses (including primitive ones), and complicated write barriers before every write access (including primitive ones), plus handling the cases where both copies of the objects are exposed (for example, in acmp). With this change, Shenandoah rewires the barriers to employ stronger to-space invariant: never expose objects in the collection set, evacuating them eagerly on reference load. Implementation rewires that used to be the write barrier handling code to every reference load, and removes other barriers (read, acmp, storeval barriers).

The change makes simpler barrier interface, provides more opportunities for performance optimizations, reduces the maintenance burden. Even though Shenandoah makes more complicated read barriers with this change, the incidence of those barriers is lower, because there are no barriers on writes anymore, and only reference loads need to be handled. This makes the change performance neutral or performance-positive on many workloads, even with simpler optimization code.

Improve Ergonomics for Sparse PRT Entry Size

This enhancement changes the ergonomics for sizing the lowest level (most quickly to access, but taking most space per element) remembered set memory storage in G1 called Sparse PRTs.

The number of entries now grow exponentially with region size instead of linearly. This means that G1 uses 4/8/16/32/64/128 entries per Sparse PRT if configured for 1/2/4/8/16/32 MB regions respectively instead of 4/8/12/16/20/24 entries.

With this change, G1 uses significantly less memory for remembered sets for applications requiring a significant amount of remembered sets. This may also result in decreased garbage collection pause times in these cases.

The ergonomically determined values may be overridden using the -XX:G1RSetSparseRegionEntries option as before.

Shenandoah Accepts Arbitrarily Low Initial Heap Size

The Shenandoah implementation has been improved to allow arbitrarily low initial heap size. Before this change, Shenandoah needed at least 10 regions to cover -Xms. With large heaps and/or larger regions, those 10 regions could use a significant amount of space. This requirement is relaxed now, and Shenandoah can run with the lowest -Xms that the shared JVM code can accept.

Improvements in Serial GC Young pause time report

With Serial GC, when Young GC fails and upgrades to Full GC, the logging messages may be confusing. In previous releases, the log would say both "Pause Full" and "Pause Young" finished at the same time, leading to double-counting the pause time. In this release, the logging is fixed to properly reflect times spent in "Young" and "Full" collections. See more at JDK-8215221.

Epsilon GC Caused Excess Metaspace Resizing Safepoints

In this release, Epsilon has been changed to accept GC requests and resize the metaspace to reduce the number of safepoints that are taken.

Before this release, the Epsilon GC was intended to provide minimal runtime overhead by not doing GC and by ignoring all incoming GC requests. However, when a metadata-heavy workload (for example, a workload having lots of classes) needed to resize the metaspace, it relied on the GC to resize the metadata at a GC safepoint. Shared GC code would enter the safepoint to call into GC for it. However, because Epsilon ignored the GC request, the safepoint would be generated, but it would not resize the metaspace. This would cause another safepoint to be generated soon afterwards without ever resizing the metaspace.

Shenandoah x86_32 support

Shenandoah now experimentally supports x86_32 in fully concurrent mode. This allows memory footprint improvements in VM-heavy workloads, when most of the memory taken by JVM are VM-native structures. This also serves as the proof Shenandoah is implementable on 32-bit platforms.

Shenandoah Changes -Xms to Mean "minimum heap size"

Before the changes in this release, -Xms was treated as setting the "initial heap size." This enabled the Shenandoah heap sizing policy to uncommit unused heap that was below that setting. With this release, -Xms is treated as providing the "minimum heap size." This change prevents Shenandoah from uncommitting unused heap that is below the -Xms setting. -Xms can now be used to fine-tune footprint vs. allocation overhead tradeoffs.

Added -XX:SoftMaxHeapSize Flag

The manageable command-line flag -XX:SoftMaxHeapSize=<bytes> has been added. Currently, it only has an effect when the Z garbage collector is enabled (-XX:+UseZGC).

When set, the GC will strive to not grow the heap beyond the specified size, unless the GC decides it's necessary to do so to avoid OutOfMemoryError. The soft max heap size is not allowed to be set to a value greater than the maximum heap size (-Xmx). When not set on the command line, it defaults to a value equal to the maximum heap size.

Being manageable, its value can be adjusted at runtime. For example, its value can be adjusted by using jcmd VM.set_flag SoftMaxHeapSize <bytes> or through the HotSpot MXBean.

Setting this flag can be useful in a number of situations, such as:

• In environments where resource usage is a concern, you might want to keep the heap footprint down while also retaining the capability to deal with a temporary increase in heap space requirement.

• When using a concurrent GC (such as ZGC), you might want to play it safe and increase the confidence level that you will not run into an allocation stall because of an unforeseen increase in allocation rate. Setting a soft max heap size encourages the GC to maintain a smaller heap, which means the GC will collect garbage more aggressively than it otherwise would, making it more resilient to a sudden increase in the application allocation rate.

Improve the Behavior of MaxRAM Settings and UseCompressedOops

The behavior of several GC Heap selection flags have been changed to better meet the expectation of users.

Prior to this change, if the heap size selection resulting from the use of these flags exceeded the maximum reachable address when UseCompressedOops is enabled, the heap size would be truncated to be within the CompressedOops range. Also, the percentage or fractional calculation performed was based on the value of MaxRAM and not the amount of physical memory available in the system. The following are the options impacted by this change:

• -XX:MaxRAMPercentage
• -XX:MaxRAMFraction
• -XX:MinRAMPercentage
• -XX:MinRAMFraction
• -XX:InitialRAMPercentage
• -XX:InitialRAMFraction
• -XX:MaxRAM

The new behavior calculates the percentage or fraction based on the host's available memory unless the user also specifies -XX:MaxRAM. In addition, UseCompressedOops is automatically disabled if the heap size resulting from the use of any of these options, including -XX:MaxRAM, is greater than can be addressed in CompressedOops mode, unless the -XX:+UseCompressedOops option is specified to override this behavior.

Note: This change only impacts 64-bit platforms.

Shenandoah Logs Report Proper Committed Heap Size

In previous releases, Shenandoah reported the max heap size as the current heap size. This reporting error resulted from changing the heap sizing scheme to per-region commit/uncommit. In this release, Shenandoah reports the proper amount of committed memory that is taken by the current heap. The changes in this release also eliminate redundant logging lines that print reserved/committed/used memory sizes. This change makes Shenandoah GC logging more consistent with other GCs. Users are advised to check their GC log parsing scripts. See JDK-8222185.

Shenandoah reduces the default number of GC threads

In previous releases, Shenandoah GC defaulted to the large number of concurrent and parallel GC threads to do the work. In many cases, this lead to taking a significant CPU toll when GC was running. In worst case, the system can be saturated with the GC work alone.

In this release, the default number of concurrent and parallel Shenandoah GC threads is trimmed down to 1/4 and 1/2 of CPU threads, respectively. Users are advised to check if their installations benefit from these new defaults, or adjust -XX:ConcGCThreads=# or -XX:ParallelGCThreads=# if needed.

Shenandoah eliminated separate forwarding pointer slot

Shenandoah uses an extra word per object to store the forwarding pointer of an object in support of concurrent evacuation. With the arrival of load reference barriers, it is possible to store the forwarding pointer in the then-unused memory of old copy of an object instead, for example use the old copy mark-word and encode the forwarding pointer there. This allows to eliminate the extra forwarding pointer word, and thus reduces memory footprint to that of regular GC.

JEP 351: ZGC: Uncommit Unused Memory

ZGC was enhanced to return unused heap memory to the operating system. This is useful for applications and environments where memory footprint is a concern.

This feature is enabled by default, but can be explicitly disabled using -XX:-ZUncommit. Furthermore, memory will not be uncommitted so that the heap size shrinks below the minimum heap size (-Xms). This means this feature will be implicitly disabled if the minimum heap size (-Xms) is configured to be equal to the maximum heap size (-Xmx).

An uncommit delay can be configured using -XX:ZUncommitDelay=<seconds> (defaults to 300 seconds). This delay specifies for how long memory should have been unused before it's eligible for uncommit.

For more details, see (JEP 351).

A jrt URI Can Only Encode Paths to Files in /modules Tree

A jrt URL is a hierarchical URI with the syntax jrt:/[$MODULE[/$PATH]]. When using the jrt file system, a java.net.URI object can be created with the java.nio.file.Path::toUri method to encode a normalized path to a file in the /modules tree. A jrt URL cannot encode a path to a file in the /packages tree. The jrt file system provider has been changed in this release so that toUri fails with IOError when it is not possible to encode the file path as a jrt URI. This change might impact tools that assume a URI can be created to locate files in the /packages tree. Tools with paths to files in /packages can use the toRealPath() method to obtain the real path (in /modules) before attempting to convert the file path to a URI.