RELEASE NOTES: JDK 14

Default ErrorListener No Longer Reports Warnings and Errors to the Console

Prior to this release, the javax.xml.transform.ErrorListener specification defined that the default ErrorListener implementation reported warnings and errors to System.err, and System.out in some cases. This requirement has been removed as of this release and the default ErrorListener now takes no action for warnings and recoverable errors; and in the case of a severe error, throws a TransformerException.

It is recommended that applications always register their own ErrorListener to ensure proper handling of warnings and errors.

Allow Discoverable javac Plugins to be Invoked by Default

javac "plugins" can now opt-in to be started by default if not started explicitly in the options passed to javac from the command-line or in the options argument of an API invocation. This behavior is enabled by implementing the method Plugin.isDefault() to return true.

toString() on Annotation Objects is Consistent Between Core Reflection and javac

Both core reflection and javac, through annotation processing, have objects representing annotations. The toString output for the two kinds of annotation objects now follow the same conventions. These conventions allow the output to be used in source code.

Removal of netscape.javascript.JSObject::getWindow Method

The obsolete netscape.javascript.JSObject::getWindow method has been removed. This method was deprecated in JDK 9. As of JDK 11, there is no longer a useful way to use this method; it always returns null.

Behavior of MulticastSocket getOption/setOption for IP_MULTICAST_LOOP Conforms With the StandardSocketOptions.IP_MULTICAST_LOOP Specification

The MulticastSocket methods getOption and setOption have been changed to conform to the behavior described in the StandardSocketOptions.IP_MULTICAST_LOOP specification. MulticastSocket.getOption(StandardSocketOptions.IP_MULTICAST_LOOP) now returns true if loopback mode is enabled. Setting MulticastSocket.setOption(StandardSocketOptions.IP_MULTICAST_LOOP, true) enables loopback mode.

InetSocketAddress.toString Format Changes for IPv6 Literals and Unresolved Addresses

The method InetSocketAddress::toString has been improved regarding the handling of IPv6 addresses. The implementation now encloses the IPv6 literal in brackets, which adheres to the specification outlined in RFC2732.

Additionally, the string format for unresolved addresses has been changed. The method now represents the literal IP address with the token <unresolved>, for example: foo/<unresolved>:80 instead of foo:80. This is based on InetAddress::toString, which returns a string of the form "hostname / literal IP address". To retrieve a string representation of the hostname, or the string form of the address if it doesn't have a hostname, use InetSocketAddress::getHostString, rather than parsing the string representation.

DatagramSocket.send and MulticastSocket.send Throw IllegalArgumentException When Socket Is Not Connected and Packet Doesn't Contain Address

The send methods defined by DatagramSocket and MulticastSocket have been changed to throw an IllegalArgumentException if the socket is not connected and the DatagramPacket doesn't have a socket address. Prior to this change, these methods threw a NullPointerException.

MulticastSocket getOption(IP_MULTICAST_IF) Returns null when outgoing interface not set

The MulticastSocket method getOption has been changed to conform to the behavior described in StandardSocketOptions.IP_MULTICAST_IF. MulticastSocket.getOption(StandardSocketOptions.IP_MULTICAST_IF) now returns null if no interface has been set.

DelegationPermission Allows Creating an Instance That Thows NPE on ::equals Call

When a DelegationPermission object is created and the principals argument does not contain a pair of principals, an IllegalArgumentException is now thrown.

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.

Plural Support in CompactNumberFormat

`java.text.CompactNumberFormatis now capable of dealing with plural forms. For example, the number ``2,000,000` is formatted to"2 Millionen"`` in `LONGstyle, whereas ``1,000,000` to"1 Million"`` in the German language.

Upgraded CLDR to v36

Locale data based on Unicode Consortium's CLDR has been upgraded to their version 36. For the detailed locale data changes, please refer to the Unicode Consortium's CLDR release notes: - http://cldr.unicode.org/index/downloads/cldr-36

Thread.countStackFrames Changed to Unconditionally Throw UnsupportedOperationException

The terminally deprecated method Thread.countStackFrames has been changed in this release to unconditionally throw UnsupportedOperationException.

This method will be removed in a future release.

Thread Suspend/Resume Are Deprecated for Removal

The following methods related to thread suspension in java.lang.Thread and java.lang.ThreadGroup have been terminally deprecated in this release:

• Thread.suspend()
• Thread.resume()
• ThreadGroup.suspend()
• ThreadGroup.resume()
• ThreadGroup.allowThreadSuspension(boolean)

These methods will be removed in a future release.

Windows 2019 Core Server Is Not Supported

Windows Core Server 2019 does not ship a dll required by JDK in order to run. Specifically, if a Java application, including a headless one, requires awt.dll, the Java runtime will exit with an exception. There is no workaround. Until this is resolved, this Windows Server configuration is not supported.

Windows 2019 Core Server Is Not Supported

Windows Core Server 2019 does not ship a dll required by JDK in order to run. Specifically, if a Java application, including a headless one, requires awt.dll, the Java runtime will exit with an exception. There is no workaround. Until this is resolved, this Windows Server configuration is not supported.

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 359: Records (Preview)

In JDK 14, the Records (JEP 359) preview feature adds a new class java.lang.Record. The java.lang package is implicitly imported on demand, that is, import java.lang.*. If code in an existing source file imports some other package on demand, for example, import com.myapp.*;, and that other package declares a type called Record, then code in the existing source file which refers to that type will not compile without change. To make the code compile, import the other package's Record type using a single-type import, for example, import com.myapp.Record;.

Removal of sun.nio.cs.map System Property

The system property sun.nio.cs.map, added in JDK 1.4.1, has been removed. It was provided for applications to help migrate from the old definition of Shift_JIS, which was equivalent to MS Windows codepage 932, to the one that is defined by IANA. Applications that are using the mapping property will need to designate the correct charset name based on their needs.

Added -XX:+AdjustStackSizeForTLS Flag

The glibc library allocates some thread-local storage (TLS) in the stack of a newly created thread, leaving less stack than requested for the thread to do its work. This is particularly a problem for threads with small stack sizes. It is an inherited issue from a well-known glibc problem, 'Program with large TLS segments fail' [0] and has been observed in Java applications. In one of the reported JVM failure instances, the issue manifests as a StackOverflowError on the process reaper thread, which has a small stack size. The java.lang.Thread constructor enables users to specify the stack size for a new thread. The created thread may encounter the TLS problem when the specified size is too small to accommodate the on-stack TLS blocks.

In JDK 8, a system property, jdk.lang.processReaperUseDefaultStackSize, was introduced to address the TLS issue only for reaper threads. Setting the property gives a bigger stack size to the reaper threads.

To address the issue for all threads, a general purpose workaround was implemented in Java which adjusts thread stack size for TLS. It can be enabled by using the AdjustStackSizeForTLS command-line option:

-XX:+AdjustStackSizeForTLS

When creating a new thread, if AdjustStackSizeForTLS is true, the static TLS area size is added to the user requested stack size. AdjustStackSizeForTLS is disabled by default.

Reference: [0] Bug 11787 - Program with large TLS segments fail

Thread Interrupt State Is Always Available

The specification for java.lang.Thread::interrupt allows for an implementation to only track the interrupt state for live threads, and previously this is what occurred. As of this release, the interrupt state of a Thread is always available, and if you interrupt a thread t before it is started, or after it has terminated, the query t.isInterrupted() will return true.

Detailed Message in NullPointerExceptions

A new option is available to provide more helpful NullPointerException messages:

 -XX:+ShowCodeDetailsInExceptionMessages

If the option is set, on encountering a null pointer, the JVM analyzes the program to determine which reference was null and then provides the details as part of NullPointerException.getMessage(). In addition to the exception message, the method, filename, and line number are also returned.

By default, this option is disabled.

Detailed Message in NullPointerExceptions

A new option is available to provide more helpful NullPointerException messages:

 -XX:+ShowCodeDetailsInExceptionMessages

If the option is set, on encountering a null pointer, the JVM analyzes the program to determine which reference was null and then provides the details as part of NullPointerException.getMessage(). In addition to the exception message, the method, filename, and line number are also returned.

By default, this option is disabled.

CDS Behavior Change With Non-existent Files During Archive Creation

In JDK 14, CDS runtime classpath validation is now more forgiving when dealing with files in the classpath that do not exist.

At CDS archive dump time, all non-existent elements in the classpath are automatically stripped. For example, if the command is:

java -cp nosuchfile.jar:hello.jar -Xshare:dump \
     -XX:SharedClassListFile=hello.classlist \
     -XX:SharedArchiveFile=hello.jsa

after removing the non-existing elements, the classpath recorded in hello.jsa becomes hello.jar.

Also, at run time, when the CDS archive is loaded, all non-existent elements in the classpath are ignored. With the previous example, all of the following commands will successfully load the archive:

(1) ` java -cp nosuchfile.jar:hello.jar -Xshare:on \ -XX:SharedArchiveFile=hello.jsa \ Hello (2) `` java -cp hello.jar -Xshare:on \ -XX:SharedArchiveFile=hello.jsa \ Hello ` (3) java -cp alsonosuchfile.jar:hello.jar -Xshare:on \ -XX:SharedArchiveFile=hello.jsa \ Hello ``

In JDK 13 and earlier, only (1) is allowed while (2) and (3) would trigger an error.

Removal of the Default keytool -keyalg Value

The default key algorithm for the keytool -genkeypair and keytool -genseckey commands has been removed. You must now specify the key algorithm by including the -keyalg option when using the -genkeypair or -genseckey commands. If the -keyalg option is not specified, the keytool will terminate with the error message: "The -keyalg option must be specified".

Weak Named Curves in TLS, CertPath, and Signed JAR Disabled by Default

Weak named curves are disabled by default by adding them to the following disabledAlgorithms security properties: jdk.tls.disabledAlgorithms, jdk.certpath.disabledAlgorithms, and jdk.jar.disabledAlgorithms. The named curves are listed below.

With 47 weak named curves to be disabled, adding individual named curves to each disabledAlgorithms property would be overwhelming. To relieve this, a new security property, jdk.disabled.namedCurves, is implemented that can list the named curves common to all of the disabledAlgorithms properties. To use the new property in the disabledAlgorithms properties, precede the full property name with the keyword include. Users can still add individual named curves to disabledAlgorithms properties separate from this new property. No other properties can be included in the disabledAlgorithms properties.

To restore the named curves, remove the include jdk.disabled.namedCurves either from specific or from all disabledAlgorithms security properties. To restore one or more curves, remove the specific named curve(s) from the jdk.disabled.namedCurves property.

Curves that are disabled through jdk.disabled.namedCurves include the following: secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1, brainpoolP320r1, brainpoolP384r1, brainpoolP512r1

Curves that remain enabled are: secp256r1, secp384r1, secp521r1, X25519, X448

Removed Deprecated java.security.acl APIs

The deprecated java.security.acl APIs have been removed. This includes the following classes in that package: Acl, AclEntry, AclNotFoundException, Group, LastOwnerException, NotOwnerException, Owner, and Permission.

Added LuxTrust Global Root 2 Certificate

The following root certificate has been added to the cacerts truststore: ``` + LuxTrust + luxtrustglobalroot2ca

DN: CN=LuxTrust Global Root 2, O=LuxTrust S.A., C=LU

```

Added 4 Amazon Root CA Certificates

The following root certificates have been added to the cacerts truststore: ``` + Amazon + amazonrootca1 DN: CN=Amazon Root CA 1, O=Amazon, C=US

• amazonrootca2 DN: CN=Amazon Root CA 2, O=Amazon, C=US

• amazonrootca3 DN: CN=Amazon Root CA 3, O=Amazon, C=US

• amazonrootca4 DN: CN=Amazon Root CA 4, O=Amazon, C=US ```

New Method to SAX ContentHandler for Handling XML Declaration

A new method declaration has been added to SAX ContentHandler to receive notification of the XML declaration. By implementing this method, applications can receive the values of version, encoding, and standalone attributes exactly as declared in the input document.

JEP 367: Remove the Pack200 Tools and API

The pack200 and unpack200 tools, added in JDK 5.0, have been removed. The class java.util.jar.Pack200 and the interfaces java.util.jar.Pack200.Packer and java.util.jar.Pack200.Unpacker have also been removed. These tools and API were deprecated for removal in Java SE 11 with the express intent to remove them in a future release. In addition, in the jar tool, the n sub-option to jar c has been removed. See JEP 367: Remove the Pack200 Tools and API for more information.

MethodHandles::privateLookupIn Requires PRIVATE Lookup Mode

MethodHandles::privateLookupIn has been changed. In this release, the caller Lookup must have both PRIVATE and MODULE access because an application intending to share intra-module access using MODULE alone will inadvertently also share deep reflection to its own module. In addition, if a Lookup object is created by Lookup::in or MethodHandles::privateLookupIn teleporting from one module to another module, the MODULE mode is dropped. In other words, MethodHandles::privateLookupIn requires that the caller lookup object must be created by a member from the caller's module and not be produced by cross-module teleporting.

For example, a lookup object L created by calling MethodHandles.privateLookupIn(C.class, caller) (where C is a class in module M1, and the caller's lookup class is in module M0) can access public members of public class D in module M2 if:

• M0 and M1 read M2, and
• D is in a package exported from M2 to at least both M0 and M1.
  

If D in M2 is accessible to M0 but not to M1, lookup object L will fail to lookup members in D in this release, but would have succeeded in previous releases.

Update Lookup::hasPrivateAccess and Lookup::defineClass spec w.r.t. full power lookup

Lookup::hasPrivateAccess intends to return true for "full-power lookup", i.e. a Lookup produced by the MethodHandles::lookup factory method where the caller class is the lookup class.

With JDK-8173978, MODULE bit indicates if this lookup object is created by a member in the same module as the lookup class. MethodHandles::privateLookupIn can produce a Lookup with MODULE bit dropped if teleporting from another module.

Lookup::hasPrivateAccess should be updated to return true if this lookup has both PRIVATE and MODULE access.

Lookup::in Throws IllegalArgumentException If requestedLookupClass Is a Primitive Type or an Array Class

java.lang.invoke.MethodHandles.Lookup::in method throws IllegalArgumentException if the given requestedLookupClass is a primitive type, void, or an array class. A Lookup object never intends to allow a lookup class of primitive type, void, or array class. Consequently, the specification of Lookup::in has been fixed in Java SE 14.

MethodType::fromMethodDescriptorString Requires "getClassLoader" Permission

MethodType::fromMethodDescriptorString has been changed in this release. When a security manager is present and the loader parameter is null, it performs a RuntimePermission("getClassLoader") security permission check. This check ensures that access to the system class loader is permitted.

Existing code that calls MethodType.fromMethodDescriptorString(desc, null) might get a SecurityException if access to the system class loader is denied. The security policy must be configured to grant the permission. Applications running without a security manager or with a non-null loader are not affected by this change.

Apache Santuario Library Updated to Version 2.1.4

The Apache Santuario library has been upgraded to version 2.1.4. As a result, a new system property com.sun.org.apache.xml.internal.security.parser.pool-size has been introduced.

This new system property sets the pool size of the internal DocumentBuilder cache used when processing XML Signatures. The function is equivalent to the org.apache.xml.security.parser.pool-size system property used in Apache Santuario and has the same default value of 20.

ExecutableElement.getReceiverType Changed to Return NOTYPE Rather Than null

The specification for ExecutableElement.getReceiverType requires it to return NOTYPE when a receiver type is not defined. The implementation has been changed to return NOTYPE in this case rather than null.

Accounting Currency Format Support

Currency format instances with accounting style, in which the amount is formatted in parentheses in some locales, can be obtained by calling NumberFormat.getCurrencyInstance(Locale) with the "u-cf-account" Unicode locale extension. For example in Locale.US, it will format to "($3.27)" instead of "-$3.27". Refer to CLDR's accounting currency format style for additional information.

DnsClient TCP Socket Timeout

The semantics of the com.sun.jndi.dns.timeout.initial property of the JNDI DNS provider implementation have been amended. The value of this timeout now uniformly applies to both UDP and TCP queries. Previously it applied only to UDP queries.

ZipFileInputStream::skip handling of negative values

When accessing a STORED entry within a Zip file using ZipFileInputStream, a negative value may be specified in order to skip backwards within the STORED entry and a negative value is returned indicating the number of bytes skipped backwards. If the specified value would move beyond the beginning of the file, the position is set to the beginning of the file and a negative value is returned indicating the number of bytes moved from the current position to the beginning of the file.

When accessing a DEFLATED entry within a Zip file using ZipFileInflaterInputStream and a negative value is specified to the skip method, an IllegalArgumentException will be thrown.

Turned Off AOT by Default and Changed Related Flags to Experimental

The default value of UseAOT has been changed from enabled to disabled, and the following AOT support related flags have been changed to experimental:

• UseAOT
• PrintAOT
• AOTLibrary

Stateless Resumption Enabled by Default for JSSE Server

Server-side JSSE now operates in stateless mode by default. 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. Applications that depend on SSLSession to list sessions cached will not find that information in stateless mode.

If stateless needs to be turned off, use the System property jdk.tls.server.enableSessionTicketExtension. Using -Djdk.tls.server.enableSessionTicketExtension=false on the command-line will turn off stateless and return the JSSE server to using the session cache.

Removed SSLv2Hello and SSLv3 From Default Enabled TLS Protocols

SSLv2Hello and SSLv3 have been removed from the default enabled TLS protocols.

After this update, if SSLv3 is removed from the jdk.tls.disabledAlgorithms security property, the SSLSocket.getEnabledProtocols(), SSLServerSocket.getEnabledProtocols(), SSLEngine.getEnabledProtocols() and SSLParameters.getProtocols() APIs will return "TLSv1.3, TLSv1.2, TLSv1.1, TLSv1". "SSLv3" will not be returned in this list.

If a client or server still needs to use the SSLv3 protocol they can do so by enabling it through the jdk.tls.client.protocols or jdk.tls.server.protocols system properties or with the SSLSocket.setEnabledProtocols(), SSLServerSocket.setEnabledProtocols() and SSLEngine.setEnabledProtocols() APIs.

Deprecated the Legacy Elliptic Curves for Removal

The following named elliptic curves supported by the SunEC provider have been deprecated:

brainpoolP256r1, brainpoolP320r1, brainpoolP384r1, brainpoolP512r1, secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3

The implementations of these curves are targeted to be removed in a subsequent JDK release. A small number of them may be replaced with a more modern implementation.

Deprecated the OracleUcrypto JCE Provider for Removal

The OracleUcrypto JCE Provider and its containing module jdk.crypto.ucrypto have been deprecated and are subject to removal in a future version of the JDK. See JEP 362 for more information.

Protected javax.crypto.Cipher Constructor Throws IAE for Non-null Invalid Arguments

The protected constructor of javax.crypto.Cipher has been changed to throw IllegalArgumentException instead of NullPointerException if the supplied arguments are deemed invalid for constructing the Cipher object. If the provider argument is null, the constructor will throw NullPointerException as before. Both exceptions are now documented in the javadoc specification of the protected constructor.

SunJCE Provider Throws NoSuchAlgorithmException for AES/GCM/PKCS5Padding

Prior to this release, the SunJCE provider incorrectly returned a Cipher instance for the "AES/GCM/NoPadding" transformation when a caller requested "AES/GCM/PKCS5Padding". The SunJCE provider now throws NoSuchAlgorithmException when "AES/GCM/PKCS5Padding" is requested. If you are impacted by this issue, the workaround is to use "AES/GCM/NoPadding" instead.

DatagramChannel.disconnect Might Leave the Channel's Socket in an Unspecified State

The DatagramChannel implementation has been updated in this release so that the disconnect method attempts to workaround Linux kernel behavior that reverts the local port to 0 after dissolving the association. The issue arises when a DatagramChannel is initially bound to an ephemeral port, connected (by calling its connect method), and then disconnected (by calling its disconnect method). The workaround in the DatagramChannel::disconnect is to attempt to re-bind the channel's socket to its original port. This usually succeeds, but if it fails, an IOException is thrown. This workaround has been used in the DatagramSocket implementation for several releases.

As part of this change, the javadoc for DatagramChannel::disconnect has been updated with an API note to make it clear that an IOException might leave the channel's socket in an unspecified state. The API note also strongly recommends that the channel be closed when the disconnect fails.

Zip File System Throws java.nio.file.NoSuchFileException When the File Does Not Exist and Is Not Being Created

The Zip File System has been updated to throw java.nio.file.NoSuchFileException (a subclass of IOException), when java.nio.file.FileSystems.newFileSystem is used to create a new file system; the specified Zip or JAR file does not exist, and the Zip provider property create is not set to true.

Using the ZIP File System (zipfs) Provider to Update a ZIP or JAR File Containing Uncompressed Entries Might Corrupt the File

Using the ZIP File System (zipfs) to update a JAR or ZIP file might corrupt that file. Corruption occurs only if the JAR or ZIP file contains a non-compressed entry. If the JAR or ZIP file contains only compressed entries, as is typical, then no data corruption occurs.

As a workaround, users can use the jar tool or the java.util.zip API to update JAR or ZIP files that contain non-compressed entries.

Clarify the Specification of ReadableByteChannel.read() and Related Methods

The specifications of the DatagramChannel.receive(), FileChannel.read(ByteBuffer,long), ReadableByteChannel.read(), and ScatteringByteChannel.read() methods have been updated in this release to specify that an IllegalArgumentException is thrown if (any of) the buffer parameter(s) is read-only. This change merely adjusts the specification to match existing long term behavior.

JEP 349: JFR Event Streaming

JDK Flight Recorder (JFR) now supports continuous monitoring of a Java application by allowing events to be consumed dynamically using a new API located in the jdk.jfr.consumer package. The feature is always enabled when using JFR, meaning recorded data up to the last second is available for both in process and out of process consumption. See JEP 349: JFR Event Streaming for more information.

Epsilon warns about Xms/Xmx/AlwaysPreTouch configuration

Many Epsilon GC users expect low latency, but may not be aware that additional configuration is needed for GCs to perform well in those conditions. It now warns about Xms/Xmx/AlwaysPreTouch configuration. These settings are not adjusted automatically, because doing so would affect startup time. These new warnings can be shunned by overriding the default logging level with -Xlog:gc=error.

Shenandoah CAS barriers improvements

Following the Load-Reference-Barriers work in JDK 13 (JDK-8221766), Shenandoah improves CAS barriers to be more efficient. This may translate to higher performance in heavily concurrent code that deals with lots of object reference CASes, e.g. with AtomicReference.compareAndSet, VarHandle.compareAndSet, Unsafe.compareAndSet, etc.

JEP 364: ZGC on macOS

The Z Garbage Collector (ZGC) is now available as an experimental feature on macOS. To enable it, use the JVM flags -XX:+UnlockExperimentalVMOptions -XX:+UseZGC. See JEP 364: ZGC on macOS for more information.

Shenandoah self-fixing barriers

Before this improvement, Shenandoah LRB barrier performance penalty for accessing forwarded objects involved resolving through the forwarding pointer, until the Update References phase fixed the affected references. A more efficient implementation ships now, where LRB self-fixes the forwarded reference on the same code path, eliminating continuous resolves for potentially hot accesses.

Self-fixing is implemented for C1 and C2 (JDK-8231087), interpreter (JDK-8232992) and runtime (JDK-8232010) barriers.

Parallel GC Improvements

Parallel GC has adopted the same task management mechanism for scheduling parallel tasks as other collectors. This might result in significant performance improvements. Because of this change, the following product flags have been obsoleted: -XX:BindGCTaskThreadsToCPUs, -XX:UseGCTaskAffinity, and -XX:GCTaskTimeStampEntries.

Epsilon does not extend TLABs to max size

Due to a simple implementation bug, Epsilon GC did not extend the size of the issued TLABs to the max size configured by user, or set by default. This bug might have introduced performance penalties and was generally confusing during performance analysis. This is now fixed and backported to 13u and 11u. Users are advised to double-check their performance results before and after this update.

Shenandoah: asynchronous object/region pinning

When dealing with JNI Get*Critical methods, Shenandoah employs object/region pinning, instead of using the GCLocker. Until now, the inefficient pinning implementation have caused real-world scalability problems on workloads that use a lot of JNI, for example gzip and graphics. This was improved, and scalability bottleneck should be resolved. This fix was also backported to 8-shenandoah and 11-shenandoah.

Shenandoah supports concurrent class unloading

As of JDK 14, Shenandoah GC supports concurrent class unloading. It improves the prior stop-the-world implementation to be fully concurrent, which minimizes the class unloading work done during Final Mark pause. This also enables class unloading for the regular GC cycles by default, in addition to already enabled class unloading during degenerated and full GC cycles. This relies heavily on runtime facilities introduced in JDK 12, and therefore not available in 11-shenandoah and 8-shenandoah.

Shenandoah arraycopy improvements

When handling Object[] arraycopy, Shenandoah used to evacuate array elements / fix references in the destination array after the copy. This is not efficient when multiple copies are done, as fixups would have to run on every copy. Plus, the fixups in the destination array do not improve the accesses to the source array.

Unfortunately, this was the only way to deal with arraycopy until the GC API was extended. In JDK 14 with GC API improvements, Shenandoah is now able to fix up object arrays at source before the arraycopy, which improves performance and opens up other optimization opportunities.

JEP 345: NUMA-Aware Memory Allocation for G1

The G1 garbage collector now tries to allocate and keep objects on the same NUMA node in the young generation across garbage collections. This is similar to Parallel GC NUMA awareness.

G1 attempts to evenly distribute Humongous and Old regions across all available NUMA nodes using a strict interleave. Placement of objects copied from young to old generation is random.

These new NUMA-Aware Memory Allocation heuristics are automatically enabled by using the -XX:+UseNUMA command line option. See JEP 345: NUMA-Aware Memory Allocation for G1 for more information.

JEP 363: Remove the Concurrent Mark and Sweep (CMS) Garbage Collector

The CMS garbage collector has been removed. -XX:UseConcMarkSweepGC and aliases -Xconcgc and -Xnoconcgc are obsoleted as well as all CMS specific options (too many to list). See JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector for more information.

JEP 365: ZGC on Windows

The Z Garbage Collector (ZGC) is now available as an experimental feature on Windows. To enable it, use the JVM flags -XX:+UnlockExperimentalVMOptions -XX:+UseZGC. See JEP 365: ZGC on Windows for more information.

Shenandoah supports JFR Leak Profiler

After the recent improvements in runtime, users should now be able to use JFR Leak Profiler with Shenandoah GC. This is only available with JDK 14 onwards.

JEP 366: Deprecate the ParallelScavenge + SerialOld GC Combination

The ParallelScavenge + SerialOld garbage collector combination has been deprecated. Any use of the UseParallelOldGC command line option, which is used to enable this garbage collection algorithm combination, will cause a deprecation warning.

The drop-in replacement is to use the ParallelScavenge + ParallelOld garbage collector through -XX:+UseParallelGC on the command line.

See JEP 366: Deprecate the ParallelScavenge + SerialOld GC Combination for more information.

OperatingSystemMXBean Methods Inside a Container Return Container Specific Data

When executing in a container, or other virtualized operating environment, the following OperatingSystemMXBean methods in this release return container specific information, if available. Otherwise, they return host specific data:

• getFreePhysicalMemorySize()
• getTotalPhysicalMemorySize()
• getFreeSwapSpaceSize()
• getTotalSwapSpaceSize()
• getSystemCpuLoad()