RELEASE NOTES: JDK 15

Notes generated: Sun Nov 03 22:03:45 CET 2024

JEPs

Issue Description
JDK-8199231 JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)
Implement cryptographic signatures using the Edwards-Curve Digital Signature Algorithm (EdDSA) as described by RFC 8032.
JDK-8227043 JEP 360: Sealed Classes (Preview)
Enhance the Java programming language with sealed classes and interfaces. Sealed classes and interfaces restrict which other classes or interfaces may extend or implement them. This is a preview language feature in JDK 15.
JDK-8220607 JEP 371: Hidden Classes
Introduce hidden classes, which are classes that cannot be used directly by the bytecode of other classes. Hidden classes are intended for use by frameworks that generate classes at run time and use them indirectly, via reflection. A hidden class may be defined as a member of an access control nest, and may be unloaded independently of other classes.
JDK-8236933 JEP 372: Remove the Nashorn JavaScript Engine
Remove the Nashorn JavaScript script engine and APIs, and the jjs tool. The engine, the APIs, and the tool were deprecated for removal in Java 11 with the express intent to remove them in a future release.
JDK-8235674 JEP 373: Reimplement the Legacy DatagramSocket API
Replace the underlying implementations of the java.net.DatagramSocket and java.net.MulticastSocket APIs with simpler and more modern implementations that are easy to maintain and debug. The new implementations will be easy to adapt to work with virtual threads, currently being explored in Project Loom. This is a follow-on to JEP 353, which already reimplemented the legacy Socket API.
JDK-8235256 JEP 374: Deprecate and Disable Biased Locking
Disable biased locking by default, and deprecate all related command-line options.
JDK-8235186 JEP 375: Pattern Matching for instanceof (Second Preview)
Enhance the Java programming language with pattern matching for the instanceof operator. Pattern matching allows common logic in a program, namely the conditional extraction of components from objects, to be expressed more concisely and safely. This is a preview language feature in JDK 15.
JDK-8209683 JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production)
Change the Z Garbage Collector from an experimental feature into a product feature.
JDK-8236934 JEP 378: Text Blocks
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.
JDK-8241457 JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector (Production)
Change the Shenandoah garbage collector from an experimental feature into a product feature.
JDK-8241787 JEP 381: Remove the Solaris and SPARC Ports
Remove the source code and build support for the Solaris/SPARC, Solaris/x64, and Linux/SPARC ports. These ports were deprecated for removal in JDK 14 with the express intent to remove them in a future release.
JDK-8242499 JEP 383: Foreign-Memory Access API (Second Incubator)
Introduce an API to allow Java programs to safely and efficiently access foreign memory outside of the Java heap.
JDK-8242303 JEP 384: Records (Second Preview)
Enhance the Java programming language with records, which are classes that act as transparent carriers for immutable data. Records can be thought of as nominal tuples. This is a preview language feature in JDK 15.
JDK-8244917 JEP 385: Deprecate RMI Activation for Removal
Deprecate the RMI Activation mechanism for future removal. RMI Activation is an obsolete part of RMI that has been optional since Java 8. No other part of RMI will be deprecated.

RELEASE NOTES

tools/javac

Issue Description
JDK-8241741

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.

core-libs/java.net

Issue Description
JDK-8237890

DatagramPacket.getPort() Returns 0 When the Port Is Not Set


In this release, the default port number for a datagram packet has been changed to 0. Previously, this value was -1, which was undocumented. The port can be retrieved by using DatagramPacket::getPort.
JDK-8243099

Added Support for SO_INCOMING_NAPI_ID Support


A new JDK-specific socket option SO_INCOMING_NAPI_ID has been added to jdk.net.ExtendedSocketOptions in this release. The socket option is Linux specific and allows applications to query the NAPI (New API) ID of the underlying device queue associated with its socket connection and take advantage of the Application Device Queue (ADQ) feature of high performance Network Interface Card (NIC) devices.
JDK-8239594

java.net.HttpClient Does Not Override Protocols Specified in SSLContext Default Parameters


During the setup of new connections, java.net.http.HttpClient now uses the default set of protocols provided by the SSLContext when negotiating the TLS handshake. In the absence of any SSLParameters explicitly supplied to the HttpClient.builder, the HttpClient has been updated to no longer override any default-selected protocols in the SSLContext. As a result, the actual TLS version that is negotiated might differ from that of previous releases, or it might even succeed or fail to negotiate when it previously might not have.
JDK-8235783

DatagramSocket::disconnect Allows an Implementation to Throw UncheckedIOException


Previously, DatagramChannel::disconnect threw an IOException while DatagramSocket::disconnect did not. As a result, the DatagramChannel::socket adapter, which calls DatagramChannel::disconnect, catches the thrown IOException and rethrows it as an Error. However, this was undocumented behavior and not user-friendly.

The DatagramChannel::socket adapter has been changed to throw an UncheckedIOException, and the specification of DatagramSocket::disconnect has been updated to document that an implementation may now throw an UncheckedIOException. This ensures consistency in behavior between DatagramSocket, DatagramChannel, and DatagramChannel::socket adapter.
JDK-8244582

Removal of Terminally Deprecated Solaris-specific SO_FLOW_SLA Socket Option


In this release, in conjunction with the removal of the Solaris port in JEP 381, the JDK-specific socket option jdk.net.ExtendedSocketOptions.SO_FLOW_SLA, which is only relevant to sockets on Solaris, and its supporting classes SocketFlow and SocketFlow.Status, have been removed.
JDK-8244958

Filtering and Ordering of Addresses Returned by Alternative Hosts File Name Service Provider


In this release, the behavior of InetAddress.getAllByName has been modified when the alternative hosts file name service is selected .

The JDK allows specifying an alternative host's file name service by using the jdk.net.hosts.file system property. The implementation of the alternative name service has been changed to take into account the values of the java.net.preferIPv4Stack and java.net.preferIPv6Addresses system properties. This affects the results returned by InetAddress.getAllByName when the host's file name service is selected. For details about java.net.preferIPv4Stack and java.net.preferIPv6Addresses, see Networking Properties in the API documentation.

core-svc/tools

Issue Description
JDK-8237354

New Option Added to jcmd for Writing a gzipped Heap Dump


A new integer option gz has been added to the GC.heap_dump diagnostic command. If it is specified, it will enable the gzip compression of the written heap dump. The supplied value is the compression level. It can range from 1 (fastest) to 9 (slowest, but best compression). The recommended level is 1.
JDK-8196729

New Option Added to jstatd for Specifying RMI Connector Port Number


A new -r <port> option has been added to the jstatd command to specify the RMI connector port number. If a port number is not specified, a random available port is used.

security-libs/javax.security

Issue Description
JDK-8239385

Support for canonicalize in krb5.conf


The 'canonicalize' flag in the krb5.conf file is now supported by the JDK Kerberos implementation. When set to true, RFC 6806 name canonicalization is requested by clients in TGT requests to KDC services (AS protocol). Otherwise, and by default, it is not requested.

The new default behavior is different from JDK 14 and previous releases where name canonicalization was always requested by clients in TGT requests to KDC services (provided that support for RFC 6806 was not explicitly disabled with the sun.security.krb5.disableReferrals system or security properties).

core-libs/java.util:i18n

Issue Description
JDK-8239480

Support for CLDR version 37


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

Localized Time Zone Name Inconsistency Between English and Other Locales


English time zone names provided by the CLDR locale provider are now correctly synthesized following the CLDR spec, rather than substituted from the COMPAT provider. For example, SHORT style names are no longer synthesized abbreviations of LONG style names, but instead produce GMT offset formats.

core-libs/java.lang

Issue Description
JDK-8241742

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.
JDK-8240094

Optimized Empty Substring Handling


The implementation of String.substring and related methods stripLeading and stripTrailing have changed in this release to avoid redundantly creating a new empty String. This may impact code that depends on unspecified behaviour and the identity of empty sub-strings.
JDK-8215401

Added isEmpty Default Method to CharSequence


java.lang.CharSequence has been updated in this release to define a default isEmpty method that tests if a character sequence is empty. Testing for, and filtering out, empty Strings and other CharSequences is a common occurrence in code and CharSequence::isEmpty can be used as a method reference. Classes that implement java.lang.CharSequence and another interface that defines isEmpty method should be aware of this addition as they may need to be modified to override the isEmpty method.
JDK-8239383

Support for Unicode 13.0


This release upgrades Unicode support to 13.0, which includes the following: - The java.lang.Character class supports Unicode Character Database of 13.0 level, which 13.0 adds 5,930 characters, for a total of 143,859 characters. These additions include 4 new scripts, for a total of 154 scripts, as well as 55 new emoji characters. - The java.text.Bidi and java.text.Normalizer classes support 13.0 level of Unicode Standard Annexes, #9 and #15, respectively. - The java.util.regex package supports Extended Grapheme Clusters based on 13.0 level of Unicode Standard Annex #29 For more detail about Unicode 13.0, refer to the Unicode Consortium's release note.

security-libs/javax.crypto:pkcs11

Issue Description
JDK-8238555

SunPKCS11 Initialization With NSS When External FIPS Modules Are in Security Modules Database


The SunPKCS11 security provider can now be initialized with NSS when FIPS-enabled external modules are configured in the Security Modules Database (NSSDB). Before this change, when such a library was configured for NSS in non-FIPS mode, the SunPKCS11 provider would throw a RuntimeException with the message "FIPS flag set for non-internal module".

This change allows the JDK to work properly with recent NSS releases in GNU/Linux operating systems when the system-wide FIPS policy is turned on.

specification/language

Issue Description
JDK-8242149

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.
JDK-8235186

JEP 375: Pattern Matching for instanceof (Second Preview)


Pattern matching for the instanceof operator is a preview feature of the Java language in JDK 15. Pattern matching allows common logic in a Java program to be expressed more concisely and safely, namely the conditional extraction of components from objects. Preview features must not be used in production, but feedback from Java developers on the usability of preview features is welcome.

core-libs/java.nio.charsets

Issue Description
JDK-8232161

Modified the MS950 charset Encoder's Conversion Table


In this release, some of the one-way byte-to-char mappings have been aligned with the preferred mappings provided by the Unicode Consortium.

hotspot/svc-agent

Issue Description
JDK-8196751

New Options Added to jhsdb for debugd Mode


Three new options have been added to the jhsdb command for the debugd mode: 1. --rmiport <port> is used to specify a RMI connector port number. If a port number is not specified, a random available port is used. 2. --registryport <port> is used to specify a RMI registry port number. This option overrides the system property sun.jvm.hotspot.rmi.port. If a port number is not specified, the system property is used. If the system property is not set, the default port 1099 is used. 3. --hostname <hostname> is used to specify a RMI connector host name. The value could be a hostname or an IPv4/IPv6 address. This option overrides the system property java.rmi.server.hostname. If a host name not specified, the system property is used. If the system property is not set, a system host name is used.

client-libs

Issue Description
JDK-8240654

Windows GDI API's memory restrictions


It has been found that some Windows GDI functions don't support all types of Java heap memory allocation schemes. This problem can cause repaint issues and printing bugs. Affected JVM flags: -XX:+UseLargePages and -XX:+UseNUMAInterleaving. The problem can be worked around by turning off the listed flags.

See: https://support.microsoft.com/en-us/help/4567569/gdi-apis-may-fail-when-large-pages-or-vad-spanning-is-used

Workaround for Windows GDI API's memory restrictions


It has been found that some Windows GDI functions don't support all types of Java heap memory allocation schemes. This problem can cause repaint issues and printing bugs. It has been worked around by allocating temporary buffers off heap.

See: https://support.microsoft.com/en-us/help/4567569/gdi-apis-may-fail-when-large-pages-or-vad-spanning-is-used

Windows GDI API's memory restrictions


It has been found that some Windows GDI functions don't support all types of Java heap memory allocation schemes. This problem can cause repaint issues and printing bugs. Affected JVM flags: -XX:+UseLargePages, -XX:+UseNUMAInterleaving, and -XX:+UseZGC. The problem can be worked around by turning off the listed flags.

See: https://support.microsoft.com/en-us/help/4567569/gdi-apis-may-fail-when-large-pages-or-vad-spanning-is-used

core-svc/javax.management

Issue Description
JDK-8234484

Added Ability to Configure Third Port for Remote JMX


JMX supports (explicit) remote network access through the configuration of two network ports (either from the command line or in a property file), by setting the following properties:

com.sun.management.jmxremote.port=<port#>
com.sun.management.jmxremote.rmi.port=<port#>

Note: If it is not specified, the second port will default to the first.

A third local port is also opened to accept (local) JMX connections. This port previously had its number selected at random, which could cause port collisions.

However, it is now possible to configure the third JMX port (local only) by using:
com.sun.management.jmxremote.local.port=<port#>
JDK-8213222

Removal of Deprecated Constant RMIConnectorServer.CREDENTIAL_TYPES


The terminally deprecated constant javax.management.remote.rmi.RMIConnectorServer.CREDENTIAL_TYPE has been removed. A filter pattern can be specified instead by using RMIConnectorServer.CREDENTIALS_FILTER_PATTERN.

hotspot/runtime

Issue Description
JDK-8230305

Cgroups v2: Container awareness


The HotSpot runtime code as well as the core libraries code in the JDK has been updated in order to detect a cgroup v2 host system when running OpenJDK within a Linux container.

Since the 8u202 release of OpenJDK, the container detection code recognized cgroup v1 (legacy) host Linux systems. With 8u372 and later releases, both versions of the underlying cgroups pseudo filesystem will be detected and corresponding container limits applied to the OpenJDK runtime.

Without this enhancement, OpenJDK would not apply container resource limits when running on a cgroup v2 Linux host system, but would use the underlying hosts' resource limits instead.
JDK-8233014

Enable ShowCodeDetailsInExceptionMessages by default


The default of the flag ShowCodeDetailsInExceptionMessages was changed to 'true'. The helpful NullPointerException messages of JEP 358 are now printed by default. The messages contain snippets of the code where the NullPointerException was raised.

App deployers should double check the output of their web applications and similar usage scenarios. The NullPointerException message could be included in application error messages or be displayed by other means in the app. This could give remote attackers valuable hints about a potential vulnerable state of the software components being used.

An example message is 'Cannot read field "c" because "a.b" is null'. The attacker knows that field b of a contains null which might be unintended and offer an opportunity for an attack. For more details of what the message can contain see the above mentioned JEP 358.
JDK-8237767

Field Layout Computation Changed


The way that field layout is computed has been changed, with more aggressive optimizations to avoid unused gaps in instances. These new optimizations can be disabled by using a new VM option -XX:-UseEmptySlotsInSupers.

For a limited time, it is possible to continue to use the old code to compute field layout with a new VM option -XX:-UseNewFieldLayout. However, this option has been deprecated in JDK 15 and the old code will be removed in a future release.
JDK-8231264

Disabled Biased-locking and Deprecated Biased-locking Flags


Biased locking has been disabled by default in this release. In addition, the VM option UseBiasedLocking along with the VM options BiasedLockingStartupDelay, BiasedLockingBulkRebiasThreshold, BiasedLockingBulkRevokeThreshold, BiasedLockingDecayTime and UseOptoBiasInlining have been deprecated. The options will continue to work as intended but will generate a deprecation warning when they are used.

Biased locking might affect performance on applications that exhibit significant amounts of uncontended synchronization, such as applications that rely on older Java Collections APIs that synchronize on every access. Hashtable and Vector are examples of these APIs. Use -XX:+BiasedLocking on the command line to re-enable biased locking. Report any significant performance regressions to Oracle with biased locking disabled.

core-libs/java.util:collections

Issue Description
JDK-8176894

Specialized Implementations of TreeMap Methods


The TreeMap class now provides overriding implementations of the putIfAbsent, computeIfAbsent, computeIfPresent, compute, and merge methods. The new implementations provide a performance improvement. However, if the function provided to the compute- or merge methods modifies the map, ConcurrentModificationException may be thrown, because the function that is provided to these methods is prohibited from modifying the map. If a ConcurrentModificationException occurs, the function must either be changed to avoid modifying the map, or the surrounding code should be rewritten to replace uses of the compute- and merge methods with conventional Map methods such as get and put.

See JDK-8227666 for further information.

security-libs/java.security

Issue Description
JDK-8237219

Disable Native SunEC Implementation by Default


The SunEC crypto provider no longer advertises curves that are not implemented by using modern formulas and techniques. Arbitrary and named curves, listed at the bottom of this note, are disabled. Commonly used named curves, secp256r1, secp384r1, secp521r1, x25519, and x448, remain supported and enabled by SunEC because they use modern techniques. Applications that still require the disabled curves from the SunEC provider can re-enable them by setting the System property jdk.sunec.disableNative to false. For example: java -Djdk.sunec.disableNative=false ....
If this property is set to any other value, the curves will remain disabled. Exceptions thrown when the curves are disabled will contain the message Legacy SunEC curve disabled, followed by the name of the curve. Methods affected by the change are KeyPair.generateKeyPair(), KeyAgreement.generateSecret(), Signature.verify(), and Signature.sign(). These methods throw the same exception class they had before when the curve was not supported.

The following curves are disabled: 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
JDK-8225069

Removal of Comodo Root CA Certificate


The following expired Comodo root CA certificate has been removed from the cacerts keystore: ``` + alias name "addtrustclass1ca [jdk]"

Distinguished Name: CN=AddTrust Class 1 CA Root, OU=AddTrust TTP Network, O=AddTrust AB, C=SE ```
JDK-8225068

Removal of DocuSign Root CA Certificate


The following expired DocuSign root CA certificate has been removed from the cacerts keystore: ``` + alias name "keynectisrootca [jdk]"

Distinguished Name: CN=KEYNECTIS ROOT CA, OU=ROOT, O=KEYNECTIS, C=FR ```
JDK-8242060

Added Revocation Checking to jarsigner


A new -revCheck option has been added to the jarsigner command to enable revocation checking of certificates.
JDK-8243424

Signature and SignatureSpi Get Parameter Methods May Return null When Unsupported


Signature.getParameters() and SignatureSpi.engineGetParameters() may return null if the underlying provider does not support returning the parameters as AlgorithmParameters. For further details, see the Signature and SignatureSpi method descriptions.
JDK-8172404

Tools Warn If Weak Algorithms Are Used


The keytool and jarsigner tools have been updated to warn users when weak cryptographic algorithms are used in keys, certificates, and signed JARs before they are disabled. The weak algorithms are set in the jdk.security.legacyAlgorithms security property in the java.security configuration file. In this release, the tools issue warnings for the SHA-1 hash algorithm and 1024-bit RSA/DSA keys.

core-libs/java.time

Issue Description
JDK-8239520

ValueRange.of(long, long, long) Does Not Throw IAE on Invalid Inputs


`java.time.temporal.ValueRange.of()methods are now correctly throwing an InvalidArgumentException on given invalid arguments. For example, ``of(5, 2, 10)` which is invalid because theminimum`` is greater than the `smallest maximum`, now throws the exception.
JDK-8244245

localizedBy() Overrides Localized Values With Default Values


java.time.format.DateTimeFormatter.localizedBy(Locale) method now honors the default locale values, such as Chronologyand/or DecimalStyle of the specified locale argument.

For example, in previous JDK releases: ` jshell> DateTimeFormatter.ofLocalizedDate(FormatStyle.FULL) .localizedBy(Locale.forLanguageTag("fa")) .format(LocalDate.now()) $3 ==> "جمعه 1 مهٔ 2020" ` the numbers are in Arabic (Western) numerals.

In JDK 15: ` jshell> DateTimeFormatter.ofLocalizedDate(FormatStyle.FULL) .localizedBy(Locale.forLanguageTag("fa")) .format(LocalDate.now()) $3 ==> "جمعه ۱ مهٔ ۲۰۲۰" ` the numbers are in Extended Arabic-Indic numerals because it is the default numbering system for the Farsi locale.

security-libs/org.ietf.jgss:krb5

Issue Description
JDK-8005819

Support cross-realm MSSFU


The support for the Kerberos MSSFU extensions [1] is now extended to cross-realm environments.

By leveraging the Kerberos cross-realm referrals enhancement introduced in the context of JDK-8215032, the 'S4U2Self' and 'S4U2Proxy' extensions may be used to impersonate user and service principals located on different realms.

[1] - https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/3bff5864-8135-400e-bdd9-33b552051d94

core-libs/java.lang.invoke

Issue Description
JDK-8238195

Lookup::defineClass Links the Class


Lookup::defineClass is specified to throw LinkageError if a linkage error occurs, but the implementation was not actually linking the class. In this release, the implementation has been changed to link the class before returning, so conforming to the specification. If Lookup::defineClass is called to define a class that fails linking, LinkageError will be thrown.
JDK-8238358

JEP 371: Hidden Classes


JEP 371 introduces hidden classes in Java 15. Hidden classes have the following implications to existing code:

  1. Class::getName traditionally returns a binary name, but for a hidden class it returns a string that contains an ASCII forward slash (/) and is therefore not a binary name. Programs that assume the returned string is a binary name might need to be updated to handle hidden classes. That said, the longstanding practice of Unsafe::defineAnonymousClass was to define classes whose names were not binary names, so some programs may already handle such names successfully.

  2. Class::descriptorString and MethodType::descriptorString returns a string that contains a ASCII dot (.) for a hidden class and therefore is not a type descriptor conforming to JVMS 4.3. Programs that assume the returned string is a type descriptor that conforms to JVMS 4.3 might need to be updated to handle hidden classes.

  3. Class::getNestMembers is changed to not throw an exception when it fails to validate a nest membership of any member listed in NestMembers attribute. Instead, Class::getNestMembers returns the nest host and the members listed in the host's NestMembers attribute that are successfully resolved and determined to have the same nest host as this class. (This means it may return fewer members that listed in NestMembers attribute.) Existing code that expects LinkageError when there is a bad nest membership might be impacted.

  4. The nestmate test in the JVM is changed to throw only IllegalAccessError when the nest membership is invalid. Some historical understanding is necessary:

  5. In Java 8, every access control failure was signaled with IllegalAccessError (IAE). Moreover, if a given access check failed with IAE once, then the same check would fail with IAE every time.

  6. In Java 11, the introduction of nest mates (JEP 181) meant that an access control failure could be signaled either with IllegalAccessError or, if nest membership was invalid, LinkageError. Still, if a given access check failed with a specific exception, then the same check would always fail with the same exception.

  7. In Java 15, the introduction of Lookup::defineHiddenClass implies that the nest host of the lookup class must be determined eagerly, when the hidden class is defined as a nestmate of the lookup class. Both Lookup::defineHiddenClass and Class::getNestHost both determine the nest host of a class in a more resilient manner than the JVM did in Java 11; namely, the API simply treats a class as self-hosted if its purported nest membership is invalid. For consistency with the API, the JVM no longer throws LinkageError when a class's nest membership is invalid, and instead treats the class as self-hosted. This means that the JVM only throws IAE from access control (because a self-hosted class will not permit any other class to access its private members). This is the behavior expected by the vast majority of user code.

  8. JVM TI GetClassSignature returns a string that contains a ASCII dot (.) for a hidden class. JVM TI agents might need updating for hidden classes if they assume the returned string from GetClassSignature is a type descriptor conforming to JVMS 4.3.

security-libs/jdk.security

Issue Description
JDK-8242260

Added forRemoval=true to Previously Deprecated ContentSigner APIs


The ContentSigner and ContentSignerParameters classes in the com.sun.jarsigner package support alternative signers and have been deprecated with forRemoval=true. When the -altsigner or -altsignerpath options are specified, the jarsigner tool produces a warning that these options are deprecated and will be removed.

tools/jpackage

Issue Description
JDK-8237490

[macos] Support for Notarizing jpackage app-image and dmg


jpackage cannot create packages on macOS that are suitable for notarization.

core-libs/javax.lang.model

Issue Description
JDK-8245146

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.

core-libs/java.text

Issue Description
JDK-8227313

Support Monetary Grouping Separator in DecimalFormat/DecimalFormatSymbols


DecimalFormat/DecimalFormatSymbols classes are now capable of dealing with grouping separators for currency values. For example, the monetary grouping separator for the German language used in Austria (the de-AT locale) is '.', whereas the monetary grouping separator in other German locales is ' '.

core-libs/java.util.jar

Issue Description
JDK-8242848

Performance Improvement for InflaterOutputStream.write


InflaterOutputStream(OutputStream out, Inflater infl, int bufLen) allows for specifying the decompressor and buffer size to be used.

InflaterOutputStream.write(byte[] b, int off, int len) was writing data using a max buffer size of 512 bytes.

Starting with JDK 15 the buffer size specified via InflaterOutputStream(OutputStream out, Inflater infl, int bufLen) will be used in calls to InflaterOutputStream.write(byte[] b, int off, int len). If the buffer size is not specified when invoking the InflaterOutputStreamconstructor, it will default to 512 bytes.

core-libs/java.rmi

Issue Description
JDK-8245068

Deprecated RMI Activation for Removal


The RMI Activation mechanism has been deprecated and may be removed in a future version of the platform. RMI Activation is an obsolete part of RMI that has been optional since Java 8. It allows RMI server JVMs to be started ("activated") upon receipt of a request from a client, instead of requiring RMI server JVMs to be running continuously. Other parts of RMI are not deprecated. See JEP 385 for further information.
JDK-8225319

Removal of RMI Static Stub Compiler (rmic)


The RMI static stub compiler rmic has been removed. The rmic tool is obsolete and has been deprecated for removal since JDK 13.

core-libs/jdk.nashorn

Issue Description
JDK-8247956

JEP 372: Remove the Nashorn JavaScript Engine


Summary

Remove the Nashorn JavaScript script engine and APIs, and the jjs tool. The engine, the APIs, and the tool were deprecated for removal in Java 11 with the express intent to remove them in a future release.

Motivation

The Nashorn JavaScript engine was first incorporated into JDK 8 via JEP 174 as a replacement for the Rhino scripting engine. When it was released, it was a complete implementation of the ECMAScript-262 5.1 standard.

With the rapid pace at which ECMAScript language constructs, along with APIs, are adapted and modified, we have found Nashorn challenging to maintain.

Non-Goals

This removal does not affect, in any way, the javax.script API.

Description

Two JDK modules will be permanently removed:

  • jdk.scripting.nashorn -- contains the jdk.nashorn.api.scripting and jdk.nashorn.api.tree packages.

  • jdk.scripting.nashorn.shell -- contains the jjs tool.

Risks and Assumptions

We assume that developers who rely on Nashorn have had enough notice of its proposed removal to make alternative arrangements. The deprecation-for-removal of Nashorn in JDK 11 was confirmed in June 2018, causing the proposed removal to be flagged at every use of the jdk.nashorn.* API and the jjs tool in JDK 11, 12, and 13. During this period, no set of credible developers expressed a clear desire to maintain Nashorn in JDK 14 and beyond.
JDK-8241749

JEP 372: Remove the Nashorn JavaScript Engine


Summary

Remove the Nashorn JavaScript script engine and APIs, and the jjs tool. The engine, the APIs, and the tool were deprecated for removal in Java 11 with the express intent to remove them in a future release.

Motivation

The Nashorn JavaScript engine was first incorporated into JDK 8 via JEP 174 as a replacement for the Rhino scripting engine. When it was released, it was a complete implementation of the ECMAScript-262 5.1 standard.

With the rapid pace at which ECMAScript language constructs, along with APIs, are adapted and modified, we have found Nashorn challenging to maintain.

Non-Goals

This removal does not affect, in any way, the javax.script API.

Description

Two JDK modules will be permanently removed:

  • jdk.scripting.nashorn -- contains the jdk.nashorn.api.scripting and jdk.nashorn.api.tree packages.

  • jdk.scripting.nashorn.shell -- contains the jjs tool.

Risks and Assumptions

We assume that developers who rely on Nashorn have had enough notice of its proposed removal to make alternative arrangements. The deprecation-for-removal of Nashorn in JDK 11 was confirmed in June 2018, causing the proposed removal to be flagged at every use of the jdk.nashorn.* API and the jjs tool in JDK 11, 12, and 13. During this period, no set of credible developers expressed a clear desire to maintain Nashorn in JDK 14 and beyond.

hotspot/compiler

Issue Description
JDK-8235673

Flags Controlling C1 Inlining Have New Names


A number of flags controlling inlining in the C1 and C2 compilers have been split up into separate flags. The C2 compiler keeps the flags with the old names, and the C1 compiler gets the new flags.

Old flags now only controlling C2 - MaxInlineLevel - MaxRecursiveInlineLevel - MaxInlineSize - MaxTrivialSize - InlineSmallCode - FreqInlineSize

New flags for C1 that replace the old ones - C1MaxInlineLevel - C1MaxRecursiveInlineLevel - C1MaxInlineSize - C1MaxTrivialSize

Deprecation

If the old flags are used in a JDK build without the C2 compiler, a deprecation warning will be printed.

security-libs/javax.net.ssl

Issue Description
JDK-8237474

Default SSLEngine Should Create in Server Role


In JDK 11 and later, javax.net.ssl.SSLEngine by default used client mode when handshaking. As a result, the set of default enabled protocols may differ to what is expected. SSLEngine would usually be used in server mode. From this JDK release onwards, SSLEngine will default to server mode. The javax.net.ssl.SSLEngine.setUseClientMode​(boolean mode) method may be used to configure the mode.
JDK-8242141

New System Properties to Configure the TLS Signature Schemes


Two new system properties have been added to customize the TLS signature schemes in JDK. jdk.tls.client.SignatureSchemes has been added for the TLS client side, and jdk.tls.server.SignatureSchemes has been added for the server side.

Each system property contains a comma-separated list of supported signature scheme names specifying the signature schemes that could be used for the TLS connections.

The names are described in the "Signature Schemes" section of the Java Security Standard Algorithm Names Specification.
JDK-8206925

Support for certificate_authorities Extension


The "certificate_authorities" extension is an optional extension introduced in TLS 1.3. It is used to indicate the certificate authorities (CAs) that an endpoint supports and should be used by the receiving endpoint to guide certificate selection.

With this JDK release, the "certificate_authorities" extension is supported for TLS 1.3 in both the client and the server sides. This extension is always present for client certificate selection, while it is optional for server certificate selection.

Applications can enable this extension for server certificate selection by setting the jdk.tls.client.enableCAExtension system property to true. The default value of the property is false.

Note that if the client trusts more CAs than the size limit of the extension (less than 2^16 bytes), the extension is not enabled. Also, some server implementations do not allow handshake messages to exceed 2^14 bytes. Consequently, there may be interoperability issues when jdk.tls.client.enableCAExtension is set to true and the client trusts more CAs than the server implementation limit.
JDK-8241039

Retired the Deprecated SSLSession.getPeerCertificateChain() Method Implementation


The implementation of the deprecated SSLSession.getPeerCertificateChain() method has been removed from the JDK in the SunJSSE provider and the HTTP client implementation. The default implementation of this method has been changed to throw UnsupportedOperationException.

SSLSession.getPeerCertificateChain() is a deprecated method and will be removed in a future release. To mitigate the removal compatibility impact, applications should use the SSLSession.getPeerCertificates() method instead. For service providers, please remove this method from the existing implementation, and do not support this method in any new implementation.
JDK-8219989

Removal of com.sun.net.ssl.internal.ssl.Provider Name


The legacy SunJSSE provider name, "com.sun.net.ssl.internal.ssl.Provider" has been removed and should no longer be used. The "SunJSSE" name should be used instead. For example, SSLContext.getInstance("TLS", "SunJSSE").

security-libs/javax.crypto

Issue Description
JDK-8172680

SunJCE Provider Supports SHA-3 Based Hmac Algorithms


The SunJCE provider has been enhanced to support HmacSHA3-224, HmacSHA3-256, HmacSHA3-384, and HmacSHA3-512. Implementations for these algorithms are available under the Mac and KeyGenerator services. The Mac service generates the keyed-hash and the KeyGenerator service generates the key for the Mac.

client-libs/java.awt

Issue Description
JDK-8210231

java.awt.Robot.delay() Method Completes With Interrupt Status Set When Interrupted


When it is interrupted, the implementation of the java.awt.Robot.delay() method has been changed to complete with the interrupt status set.

If a thread is interrupted while waiting in the java.awt.Robot.delay() method, then this method returns immediately with the interrupt status set. If the interrupted status is already set, this method returns immediately with the interrupt status set.

core-libs/java.util.regex

Issue Description
JDK-8214245

Case Insensitive Matching Doesn't Work Correctly for Some Character Classes


The Java regular expression engine supports the case insensitive mode. When this mode is turned on, the engine is supposed to match the input text without regard to the case of the characters it consists of.

However, the current implementation of matching against some named character classes (those that are encoded with \p{name} or \P{name} constructs) fails to respect the case insensitive mode.

This fix makes these character classes behave consistently with respect to case sensitivity. When the regular expression engine operates in the case insensitive mode, the named character classes will match the input characters without regard to their case: lower case, upper case, or title case.

tools/javadoc(tool)

Issue Description
JDK-8237909

Standard Doclet Index Files Compression


The Standard Doclet no longer generates pre-compressed index files. Decisions about compression are now left to the underlying means of delivery (for example, application layer protocols such as HTTP).

hotspot/gc

Issue Description
JDK-8243628

Deprecated -XX:ForceNUMA Option


The VM option ForceNUMA is deprecated. Use of this option will produce a deprecation warning. This option will be removed in a future release.

This option has always been disabled by default. It exists to support testing of NUMA-related code paths when running on a single node / UMA platform.
JDK-8209683

JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production)


The Z Garbage Collector (ZGC) is now ready for use in production and no longer marked as an experimental feature. ZGC is enabled by using the -XX:+UseZGC command-line option (using -XX:+UnlockExperimentalVMOptions is no longer needed).

See JEP 377 for more details.
JDK-8241670

Improved Ergonomics for G1 Heap Region Size


The default heap region size calculation has been changed to return larger regions by default. The calculation still aims to have 2048 regions, but two aspects have changed:

  • Only the maximum heap size is considered. The old calculation also took the initial heap size into consideration, but this can give unexpected behavior when no heap size is set.
  • The region size is rounded up to the nearest power of 2 instead of down. This will return larger region sizes in cases where the maximum heap size is not a power of 2.

These changes improve startup and runtime performance.
JDK-8245002

Disabling NUMA Interleaving on Windows


-XX:+UseNUMAInterleaving has no effect on Windows in this release. It was found that GDI APIs used by java2d don't support the memory reservation scheme used for NUMA interleaving. The JVM detects this problem and both warns about this and turns off NUMA interleaving. See: https://support.microsoft.com/en-us/help/4567569/gdi-apis-may-fail-when-large-pages-or-vad-spanning-is-used
JDK-8228991

Obsolete -XX:UseAdaptiveGCBoundary


The VM option UseAdaptiveGCBoundary is obsolete. Use of this option will produce an obsolete option warning but will otherwise be ignored.

This option was previously disabled by default, and enabling it only had an effect when also using -XX:+UseParallelGC. Enabling it was intended to provide a performance benefit for some applications. However, it has been disabled by default for a long time because of crashes and performance regressions.
JDK-8245000

Disabling large pages on Windows


-XX:+UseLargePages has no effect on Windows in this release. It was found that GDI APIs used by java2d don't support large pages. The JVM detects this problem and both warns about this and reverts to using small pages. See: https://support.microsoft.com/en-us/help/4567569/gdi-apis-may-fail-when-large-pages-or-vad-spanning-is-used

FIXED ISSUES

client-libs

Priority Bug Summary
P2 JDK-8240654 Windows GDI functions can fail and cause severe UI application repaint issues
P3 JDK-8233827 Enable screenshots in the enhanced failure handler on Linux/macOS
P3 JDK-8235638 NPE in LWWindowPeer.getOnscreenGraphics()
P4 JDK-8236506 [macosx] Some datatransfer classes were loaded on startup
P4 JDK-8238085 PIT: javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java fails on mac

client-libs/2d

Priority Bug Summary
P2 JDK-8244818 [macos] Java2D Queue Flusher crash while moving application window to external monitor
P2 JDK-8233006 freetype incorrectly adjusts advances when emboldening rotated glyphs
P3 JDK-8244621 [macos10.15] Garbled FX printing plus CoreText warnings on Catalina when building with Xcode 11
P3 JDK-8220150 [macos] macos10.14 Mojave returns anti-aliased glyphs instead of aliased B&W glyphs
P3 JDK-8242557 Add length limit for strings in PNGImageWriter
P3 JDK-8221741 ClassCastException can happen when fontconfig.properties is used
P3 JDK-8235147 Release HDC from passiveDCList sooner
P3 JDK-8238942 Rendering artifacts with LCD text and fractional metrics
P3 JDK-8230672 Specification for java.awt.FontMetrics.getMaxAdvance() is too prescriptive.
P3 JDK-8224109 Text spaced incorrectly by drawString under rotation with fractional metrics
P3 JDK-8242004 TextLayout throws Exception with a non-invertible transform
P3 JDK-8231556 Wrong font ligatures used when 2 versions of same font used
P4 JDK-8235520 [macosx] Delete NSView based direct rendering mechanism
P4 JDK-8238075 [OGL] Delete unused properties
P4 JDK-8223090 Clean up obsolete logic & reference to Amble fonts.
P4 JDK-8241829 Cleanup the code for PrinterJob on windows
P4 JDK-8239149 Cleanups in SunFontManager.java and TrueTypeFont.java
P4 JDK-8240342 Custom composite is ignored when printing an opaque image to a page
P4 JDK-5085520 Inconsistency in spec for RenderingHints.entrySet()
P4 JDK-8236996 Incorrect Roboto font rendering on Windows with subpixel antialiasing
P4 JDK-8235904 Infinite loop when rendering huge lines
P4 JDK-8213129 java/awt/font/FontNames/LocaleFamilyNames.java times out in Win7
P4 JDK-8223935 PIT: java/awt/font/WindowsIndicFonts.java fails on windows10
P4 JDK-8242325 Remove VIS version of medialib
P4 JDK-8239091 Reversed arguments in call to strstr in freetype "debug" code.
P4 JDK-8196181 sun/java2d/GdiRendering/InsetClipping.java fails
P4 JDK-8197797 Test java/awt/Graphics2D/DrawString/RotTransText.java fails on Windows

client-libs/demo

Priority Bug Summary
P4 JDK-8237746 Fixing compiler warnings in src/demo/share/jfc

client-libs/java.awt

Priority Bug Summary
P2 JDK-8242174 [macos] The NestedModelessDialogTest test make the macOS unstable
P2 JDK-8242498 Invalid "sun.awt.TimedWindowEvent" object leads to JVM crash
P2 JDK-8232744 j.awt.Window::setShape(Shape) paints visible artifacts outside of the given shape
P3 JDK-7185258 [macOS] Deadlock in SunToolKit.realSync()
P3 JDK-8230926 [macosx] Two apostrophes are entered instead of one with "U.S. International - PC" layout
P3 JDK-8238575 DragSourceEvent.getLocation() returns wrong value on HiDPI screens (Windows)
P3 JDK-8176359 Frame#setMaximizedbounds not working properly in multi screen environments
P3 JDK-8221823 Requested JDialog width is ignored
P3 JDK-8210231 Robot.delay() catches InterruptedException and prints stacktrace to stderr
P3 JDK-8231564 setMaximizedBounds is broken with large display scale and multiple monitors
P3 JDK-8225126 Test SetBoundsPaintTest.html failed on Windows when desktop is scaled
P3 JDK-8238936 The crash in XRobotPeer when the custom GraphicsDevice is used
P3 JDK-8243925 Toolkit#getScreenInsets() returns wrong value on HiDPI screens (Windows)
P4 JDK-8226806 [macOS 10.14] Methods of Java Robot should be called from appropriate thread
P4 JDK-8237243 [macOS] java/awt/event/KeyEvent/DisabledTargetF10/DisabledTargetF10.html fails
P4 JDK-8241087 Build failure with VS 2019 (16.5.0) due to C2039 and C2873
P4 JDK-8240290 Clean the "libawt_xawt" library from code for macOS
P4 JDK-8238276 ComponentPeer.xxxImage are not implemented in some peers
P4 JDK-8176040 Documentation of java.awt.Rectangle.add(java.awt.Point) is wrong.
P4 JDK-8240518 Incorrect JNU_ReleaseStringPlatformChars in Windows Print
P4 JDK-8238741 java.awt.Robot(GraphicsDevice) constructor does not follow the spec
P4 JDK-8028701 java/awt/Focus/ShowFrameCheckForegroundTest/ShowFrameCheckForegroundTest.java fails
P4 JDK-8196019 java/awt/Window/Grab/GrabTest.java fails on Windows
P4 JDK-8234706 MenuPeer cleanup
P4 JDK-8239124 Minimize the usage of AwtGraphicsConfigDataPtr in native
P4 JDK-8235739 Rare NPE at WComponentPeer.getGraphics()
P4 JDK-8245938 Remove unused print_stack(void) method from XToolkit.c
P4 JDK-8237049 Rollback the workaround for JDK-4533057
P4 JDK-8223108 Test java/awt/EventQueue/NonComponentSourcePost.java is unstable
P4 JDK-8236163 The first getDefaultToolkit() hangs if invoked during the process's shutdown.
P4 JDK-8233573 Toolkit.getScreenInsets(GraphicsConfiguration) may throw ClassCastException
P4 JDK-8239819 XToolkit: Misread of screen information memory

client-libs/java.awt:i18n

Priority Bug Summary
P3 JDK-8239583 [AIX] simplify the native references in X input methods

client-libs/javax.accessibility

Priority Bug Summary
P2 JDK-8249278 Revert JDK-8226253 which breaks the spec of AccessibleState.SHOWING for JList
P3 JDK-8226253 JAWS reports wrong number of radio buttons when buttons are hidden

client-libs/javax.imageio

Priority Bug Summary
P3 JDK-8238842 AIOOBE in GIFImageReader.initializeStringTable
P3 JDK-6532025 GIF reader throws misleading exception with truncated images
P4 JDK-8195841 PNGImageReader.readNullTerminatedString() doesnt check for non-null terminated strings with length equal to maxLen

client-libs/javax.sound

Priority Bug Summary
P4 JDK-8238738 AudioSystem.getMixerInfo() takes about 30 sec to report a gone audio device
P4 JDK-8236980 Cleanup of toString methods in JavaSound
P4 JDK-8238567 SoftMainMixer.processAudioBuffers(): Wrong handling of stoppedMixers

client-libs/javax.swing

Priority Bug Summary
P2 JDK-8249251 [dark_mode ubuntu 20.04] The selected menu is not highlighted in GTKLookAndFeel
P2 JDK-8241291 JCK test javax_swing/text/DefaultStyledDocument/ElementSpec/ESpecCtor.html fails
P2 JDK-8246263 jdk is not yet ready for new Copyright line.
P3 JDK-8239312 [macOS] javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java
P3 JDK-8231042 [macos] JFileChooser creates new folder on ESC
P3 JDK-8223788 [macos] JSpinner buttons in JColorChooser dialog may capture focus using TAB Key.
P3 JDK-8239902 [macos] Remove direct usage of JSlider, JProgressBar classes in CAccessible class
P3 JDK-7020860 BasicTreeUI contains getters/setters with unclear spec
P3 JDK-8216329 Cannot resize CheckBoxItemMenu in Synth L&F with setHorizontalTextPosition
P3 JDK-8245668 closed test javax/swing/JComboBox/4765319/bug4765319.java fails on windows
P3 JDK-8222759 com.sun.java.swing.plaf.gtk.GTKLookAndFeel has unnecessary casts to GTKStyleFactory
P3 JDK-8234913 Improve parsing of Length Units in javax/swing/text/html/CSS
P3 JDK-8235818 Inline information from broken external links in java.desktop
P3 JDK-8236635 JTabbedPane preferred size calculation is wrong for SCROLL_TAB_LAYOUT.
P3 JDK-8224475 JTextPane does not show images in HTML rendering
P3 JDK-8241078 OOM error parsing HTML with large 
 Tag text
P3 JDK-8040630 Popup menus and tooltips flicker with previous popup contents when first shown
P3 JDK-8153090 TAB key cannot change input focus after the radio button in the Color Selection dialog
P3 JDK-8239334 Tab Size does not work correctly in JTextArea with setLineWrap on
P3 JDK-8226230 Test javax/swing/JInternalFrame/8020708/bug8020708.java fails on Ubuntu
P3 JDK-8241228 Test jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java is failing
P3 JDK-8244557 test/jdk/javax/swing/JTabbedPane/TestBackgroundScrollPolicy.java failed
P3 JDK-8226464 TitledBorder label appears cut off on hidpi devices
P3 JDK-8234733 We can't distinguish if the spinner button is pressed or unpressed
P3 JDK-8232243 Wrong caret position in JTextPane on Windows with a screen resolution > 100%
P4 JDK-8238813 [macos] closed test javax/swing/UIDefaults/4280340/bug4280340.java fails on macos
P4 JDK-8238719 [macOS] Delete the property which use deprecated prefix "com.apple.macos."
P4 JDK-8238824 [macos] javax/swing/JSpinner/4840869/bug4840869.java fails on macos
P4 JDK-8229856 [macos] Opening a menu on a JTextField can clear the text selection
P4 JDK-8152332 [macosx] JFileChooser cannot be serialized on Mac OS X
P4 JDK-8146330 [macosx] UIDefaults.keys() different size than UIDefaults.keySet()
P4 JDK-8208566 [TEST_BUG] javax\swing\text\GlyphPainter2\6427244\bug6427244.java: Test failed
P4 JDK-8233584 [Win LAF] When navigating the contents of the file list changes in Win LAF
P4 JDK-8240202 A few client tests leave mouse buttons pressed
P4 JDK-8245157 Deproblemlist closed javax/swing/JSpinner/4840869.java
P4 JDK-8245273 Deproblemlist javax/swing/DataTransfer/DefaultNoDrop/DefaultNoDrop.java
P4 JDK-8213123 javax/swing/JButton/4368790/bug4368790.java fails on mac
P4 JDK-8196094 javax/swing/JFileChooser/8002077/bug8002077.java fails
P4 JDK-8240633 Memory leaks in the implementations of FileChooserUI
P4 JDK-8240877 NPE at javax.swing.text.html.FormView.appendBuffer with null option values
P4 JDK-8240690 Race condition between EDT and BasicDirectoryModel.FilesLoader.run0()
P4 JDK-8042376 Test closed/javax/swing/JPopupMenu/4791569/bug4791569.java fails with Accelerator didn't work
P4 JDK-8067986 Test javax/swing/JComboBox/ConsumedKeyTest/ConsumedKeyTest.java fails
P4 JDK-8178028 Typing 'C' cannot change the tab layout to WRAP_TAB_LAYOUT
P4 JDK-8172269 When checking the default behaviour for a scroll tab layout and checking the 'opaque' checkbox, the area behind tabs is not red.

core-libs

Priority Bug Summary
P2 JDK-8245722 32-bit build failures after JDK-8243491
P2 JDK-8246050 Improve scalability of MemoryScope
P2 JDK-8246095 Tweaks to memory access API
P3 JDK-8243491 Implementation of Foreign-Memory Access API (Second Incubator)
P3 JDK-8248011 Improve javadoc of Foreign Memory Access API
P3 JDK-8247696 Incorrect tail computation for large segments in AbstractMemorySegmentImpl::mismatch
P3 JDK-8242499 JEP 383: Foreign-Memory Access API (Second Incubator)
P3 JDK-8239563 Reduce public exports in dynamic libraries built from JDK static libraries
P3 JDK-8225361 Start of release updates for JDK 15
P3 JDK-8230772 Umbrella: JDK 15 terminal deprecations
P3 JDK-8241627 Updating ASM to 8.0.1
P4 JDK-8231111 Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy
P4 JDK-8243539 Copyright info (Year) should be updated for fix of 8241638
P4 JDK-8247115 Fix typos in java.lang.invoke and java.lang
P4 JDK-8238380 java.base/unix/native/libjava/childproc.c "multiple definition" link errors with GCC10
P4 JDK-8246040 java/foreign/TestAddressHandle fails on big endian platforms
P4 JDK-8241144 Javadoc is not generated for new module jdk.nio.mapmode
P4 JDK-8237521 Memory Access API fixes for 32-bit
P4 JDK-8241014 Miscellaneous typos in documentation comments
P4 JDK-8249205 Remove unnecessary trademark symbols
P4 JDK-8240725 Some functions might not work with CJK character
P4 JDK-8242230 Whitespace typos, relaxed javadoc, formatting
P5 JDK-8242366 Fix JavaDoc warnings
P5 JDK-8237818 Typo in Unsafe: resposibility
P5 JDK-8241727 Typos: empty lines in javadoc, inconsistent indents, etc. (core-libs only)
P5 JDK-8241760 Typos: empty lines in javadoc, inconsistent indents, etc. (net and nio)
P5 JDK-8245111 Update doc comments for improved processing by the Standard Doclet

core-libs/java.io

Priority Bug Summary
P3 JDK-8247896 Invalid (@throw) tags in 2 java.io classes
P4 JDK-8249700 java/io/File/GetXSpace.java should be added to exclude list, and not @ignore-d
P4 JDK-8244936 Reduce JNI overhead of accessing FileDescriptor
P4 JDK-8246338 Reduce overhead of normalizing file paths
P4 JDK-8246451 Reduce overhead of normalizing file paths with trailing slash
P4 JDK-8241921 Remove leftover diagnostic from test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java
P4 JDK-8246592 Simplify checking of boolean file attributes

core-libs/java.io:serialization

Priority Bug Summary
P2 JDK-8248233 Avoid superfluous Class::isRecord invocations during deserialization
P2 JDK-8247532 Records deserialization is slow
P3 JDK-8238763 ObjectInputStream readUnshared method handling of Records
P3 JDK-8247789 Remove use of reflection from test/jdk/java/io/Serializable/records/StreamRefTest.java

core-libs/java.lang

Priority Bug Summary
P2 JDK-8240704 ProcessBuilder/checkHandles/CheckHandles.java failed "AssertionError: Handle use increased by more than 10 percent."
P3 JDK-8246098 API for Class::permittedSubclasses should clarify if returned elements are ordered or not
P3 JDK-8230800 Clarify String::stripIndent javadoc when string ends with line terminator
P3 JDK-8240971 Fix CSS styles in some doc comments
P3 JDK-8247899 HTML errors and warnings in threadPrimitiveDeprecation.html
P3 JDK-8245958 j.l.Record need to mention that canonical constructor may not be public
P3 JDK-8238239 java.lang.Record spec clarifications
P3 JDK-8241100 Make Boolean, Character, Byte, and Short implement Constable
P3 JDK-8227045 Preview APIs support for sealed classes
P3 JDK-8245398 Remove addition preview adornment from String::formatted
P3 JDK-8243168 Remove addition preview adornment from String::stripIndent and String::translateEscapes
P3 JDK-8241742 Remove the preview status for methods introduced for Text Blocks
P3 JDK-8230744 Several classes throw OutOfMemoryError without message
P3 JDK-8247444 Trust final fields in records
P3 JDK-8217475 Unexpected StackOverflowError in "process reaper" thread
P3 JDK-8239383 Update Unicode Data Files to 13.0.0
P3 JDK-8239893 Windows handle Leak when starting processes using ProcessBuilder
P4 JDK-8215401 Add isEmpty default method to CharSequence
P4 JDK-8241374 add Math.absExact
P4 JDK-8237878 Archive ModuleLoaderMap mapper
P4 JDK-8245658 Arrays.java has two occurrences of bad unicode constants in Javadoc.
P4 JDK-8241964 Clean up java.lang.Class javadoc
P4 JDK-8236183 cleanup Java_jdk_internal_reflect_Reflection_getCallerClass naming
P4 JDK-8233795 Consider adding a notion of a Value-based class to API Documentation index
P4 JDK-8236075 Minor bootstrap improvements
P4 JDK-8241947 Minor comment fixes for system property handling
P4 JDK-8237576 Missing import in macosx/../ClassLoaderHelper
P4 JDK-8241649 Optimize Character.toString
P4 JDK-8240094 Optimize empty substring handling
P4 JDK-8239365 ProcessBuilder test modifications for AIX execution
P4 JDK-8232846 ProcessHandle.Info command with non-English shows question marks
P4 JDK-8240524 Remove explicit type argument in test jdk/java/lang/Boolean/MakeBooleanComparable.java
P4 JDK-8230771 Remove terminally deprecated constructors in java.base
P4 JDK-8244855 Remove unused "getParent" function from Windows jni_util_md.c
P4 JDK-8242208 Use Method.getParameterCount where applicable

core-libs/java.lang.invoke

Priority Bug Summary
P2 JDK-8242012 Drop the uniqueness guarantee from the suffix of the name of a hidden class
P2 JDK-8238358 Implementation of JEP 371: Hidden Classes
P3 JDK-8245596 Clarify Lookup::defineHiddenClass spec @throws IAE if the bytes has ACC_MODULE flag set
P3 JDK-8218173 exception during StringConcatFactory clinit breaks string concat with no fallback
P3 JDK-8243574 java.lang.invoke.InvokerBytecodeGenerator.ClassData should be package-private
P3 JDK-8220607 JEP 371: Hidden Classes
P3 JDK-8238195 Lookup::defineClass should link the class to match the specification
P3 JDK-8245061 Lookup::defineHiddenClass should throw ClassFormatError if the constant_pool entry at the this_class index is not Class_info structure
P3 JDK-8245432 Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version
P3 JDK-8244961 MethodHandles::privateLookupIn throws NPE when called during initPhase2
P3 JDK-8235521 Replacement API for Unsafe::ensureClassInitialized
P3 JDK-8246632 StringConcatFactory::makeConcatWithConstants no longer throws NullPointerException when an unexpected constant is null
P3 JDK-8243274 suppress warnings in LookupDefineClass microbenchmarks due to JDK-8243156
P4 JDK-8244413 Avoid rebinds in MethodHandle.viewAsType
P4 JDK-8245959 Extend String concat testing to account for folded constants
P4 JDK-8246152 Improve String concat bootstrapping
P4 JDK-8240242 improve the javadoc for Lookup::dropLookupModes w.r.t. dropping UNCONDITIONAL
P4 JDK-8246241 LambdaFormEditor should use a transform lookup key that is not a SoftReference
P4 JDK-8230301 Re-examine hardcoded defaults in GenerateJLIClassesPlugin
P4 JDK-8245756 Reduce bootstrap cost of StringConcatFactory prependers
P4 JDK-8245094 Reduce overhead of initializing the StringConcatFactory default strategy
P4 JDK-8245455 Remove alternative StringConcatFactory strategies
P4 JDK-8245024 Simplify and eagerly initialize StringConcatFactory
P4 JDK-8245969 Simplify String concat constant folding
P4 JDK-8243575 Trivial javadoc fix of j.l.i.MethodHandles::arrayElementVarHandle
P4 JDK-8243598 Typos in java.lang.invoke package-info

core-libs/java.lang.module

Priority Bug Summary
P3 JDK-8243666 ModuleHashes attribute generated for JMOD and JAR files depends on timestamps
P3 JDK-8243596 ModuleLayer::parents should return an unmodifiable list
P4 JDK-8237484 Improve module system bootstrap
P4 JDK-8241770 Module xxxAnnotation() methods throw NCDFE if module-info.class found as resource in unnamed module
P4 JDK-8240734 ModuleHashes attribute not reproducible between builds
P4 JDK-8238599 Refactor and simplify implAddOpensToAllUnnamed
P4 JDK-8247212 Use assistant markup in java.lang.module.ModuleDescriptor
P5 JDK-8236705 Use single character variant of String.replace when applicable

core-libs/java.lang:class_loading

Priority Bug Summary
P3 JDK-8240975 Extend NativeLibraries to support explicit unloading
P3 JDK-8228336 Refactor native library loading implementation
P4 JDK-8247785 Small clarification of the javadoc about builtin class loaders

core-libs/java.lang:reflect

Priority Bug Summary
P3 JDK-8230047 Remove legacy java.lang.reflect.ProxyGenerator_v49
P4 JDK-8202469 (ann) Type annotations on type variable bounds that are also type variables are lost
P4 JDK-8245678 Avoid allocations in Executable.getAllGenericParameterTypes
P4 JDK-8225540 In core reflection note whether returned annotations are declaration or type annotations
P4 JDK-8241789 Make citations of JLS and JVMS consistent in java.lang.Class
P4 JDK-8237805 Use inline @jls @jvms in core libs where appropriate

core-libs/java.math

Priority Bug Summary
P4 JDK-8241097 java/math/BigInteger/largeMemory/SymmetricRangeTests.java requires -XX:+CompactStrings
P4 JDK-8240624 Note mapping of RoundingMode constants to equivalent IEEE 754-2019 policy

core-libs/java.net

Priority Bug Summary
P2 JDK-8241378 j.net.URLConnection::getHeaderFieldKey(int) behavior does not reliably conform to its specification
P2 JDK-8241389 URLConnection::getHeaderFields returns result inconsistent with getHeaderField/Key for FileURLConnection, FtpURLConnection
P3 JDK-8246132 AsynchronousSocketChannelNAPITest failing with a NotYetConnectedException
P3 JDK-8248703 Clarify the behavior of java.net.NetworkInterface::equals
P3 JDK-7021373 DatagramPacket exception conditions are not clear
P3 JDK-8243999 DatagramSocket and MulticastSocket constructors don't specify how a null InetAddress is handled
P3 JDK-8243507 DatagramSocket constructors don’t always specify what happens when passed invalid parameters
P3 JDK-8244933 DatagramSocket.connect does not specify that it may cause datagrams in the socket receive buffer to be discarded
P3 JDK-8241138 http.nonProxyHosts=* causes StringIndexOutOfBoundsException in DefaultProxySelector
P3 JDK-8242999 HTTP/2 client may not handle CONTINUATION frames correctly
P3 JDK-8241786 Improve heuristic to determine default network interface on macOS
P3 JDK-8237571 java/net/DatagramSocket/SendCheck.java is failing on Solaris
P3 JDK-8234718 java/net/httpclient tests should cover TLSv1.3
P3 JDK-8238990 java/net/httpclient/HandshakeFailureTest.java failed against TLSv1.3 on Windows
P3 JDK-8238740 java/net/httpclient/whitebox/FlowTestDriver.java should not specify a TLS protocol
P3 JDK-8239052 java/net/httpclient/whitebox/SSLEchoTubeTestDriver.java failed with BufferUnderflowException against TLSv1.3
P3 JDK-8245517 java/net/SocketOption/AfterClose.java fails with Invalid value 'READ_ONLY'
P3 JDK-8235674 JEP 373: Reimplement the Legacy DatagramSocket API
P3 JDK-8244958 preferIPv4Stack and preferIPv6Addresses do not affect addresses returned by HostsFileNameService
P3 JDK-8230211 Prepare DatagramSocket for alternative DatagramSocketImpl
P3 JDK-8241072 Reimplement the Legacy DatagramSocket API
P3 JDK-8244582 Remove terminally deprecated Solaris-specific SO_FLOW_SLA socket option
P3 JDK-8183369 RFC unconformity of HttpURLConnection with proxy
P3 JDK-8241336 Some java.net tests failed with NoRouteToHostException on MacOS with special network configuration
P3 JDK-8244853 The static build of libextnet is missing the JNI_OnLoad_extnet function
P4 JDK-8238386 (sctp) jdk.sctp/unix/native/libsctp/SctpNet.c "multiple definition" link errors with GCC10
P4 JDK-8237075 @since tag missing from DatagramSocket and MulticastSocket methods
P4 JDK-8245569 Add jtreg tests for SO_INCOMING_NAPI_ID
P4 JDK-8244652 Add test for non utf-8 response handling by websocket client
P4 JDK-8243488 Add tests for set/get SendBufferSize and getReceiveBufferSize in DatagramSocket
P4 JDK-8236105 Behaviors of DatagramSocket/DatagramChannel::socket send methods are not always consistent
P4 JDK-8237817 Clean up net-properties.html
P4 JDK-8238231 Custom DatagramSocketImpl's create method not called when with protected constructor
P4 JDK-8237890 DatagramPacket::getSocketAddress doesn't specify what happens if address or port are not set
P4 JDK-8241988 DatagramSocket incorrectly caches the first set of socket options
P4 JDK-8235783 DatagramSocket::connect and DatagramSocket::disconnect should allow an implementation to throw UncheckedIOException
P4 JDK-8243246 HTTP Client sometimes gets java.io.IOException -> Invalid chunk header byte 32
P4 JDK-8244205 HTTP/2 tunnel connections through proxy may be reused regardless of which proxy is selected
P4 JDK-8236596 HttpClient leaves HTTP/2 sockets in CLOSE_WAIT, when using proxy tunnel
P4 JDK-8244031 HttpClient should have more tests for HEAD requests
P4 JDK-8235459 HttpRequest.BodyPublishers#ofFile(Path) assumes the default file system
P4 JDK-8237470 HttpResponse.BodySubscriber::ofFile throws UOE with non-default file systems
P4 JDK-8238579 HttpsURLConnection drops the timeout and hangs forever in read
P4 JDK-8240533 Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.
P4 JDK-8243408 Inconsistent Exceptions are thrown by MulticastSocket when sending a DatagramPacket to port 0
P4 JDK-8240754 Instrument FlowTest.java to provide more debug traces.
P4 JDK-8238270 java.net HTTP/2 client does not decrease stream count when receives 204 response
P4 JDK-8246431 java/net/httpclient/PathSubscriber tests fail due to missing FilePermission
P4 JDK-8235925 java/net/Socket/HttpProxy.java fails on IPv4 only hosts and other small cleanups
P4 JDK-8239594 jdk.tls.client.protocols is not respected
P4 JDK-8240921 Minor correction to HttpResponse.BodySubscribers example
P4 JDK-8237896 MulticastSocket should link to DatagramChannel as an alternative for multicasting.
P4 JDK-8059309 network tests fail with "java.net.SocketException: Couldn't obtain phys addr" when run as "root"
P4 JDK-8242186 Reduce allocations in URLStreamHandler.parseURL for some cases
P4 JDK-8245828 Remove unnecessary NetworkPermission checks from jdk/net/ExtendedSocketOptions.java
P4 JDK-8243099 SO_INCOMING_NAPI_ID support
P4 JDK-8239595 ssl context version is not respected
P4 JDK-5064980 URI compareTo inconsistent with equals for mixed-case escape sequences
P4 JDK-8240666 Websocket client's OpeningHandshake discards the HTTP response body
P4 JDK-8236859 WebSocket over authenticating proxy fails with NPE
P5 JDK-8129841 Update comment for Java_java_net_Inet6AddressImpl_getHostByAddr

core-libs/java.nio

Priority Bug Summary
P2 JDK-8250770 Net.java translateToSocketException does not handle IOException
P3 JDK-8211917 (zipfs) Creating or updating a JAR file system should put the MANIFEST.MF at the start
P3 JDK-8239556 (zipfs) remove ExistingChannelCloser facility in zipfs implementation
P3 JDK-8247880 bad HTML(href==...) in table
P3 JDK-8247959 doclint errors in NIO code
P3 JDK-8208281 java/nio/channels/AsynchronousSocketChannel/Basic.java timed out
P3 JDK-8236804 java/nio/channels/FileChannel/MapWithSecurityManager.java should be run in othervm mode
P3 JDK-8246729 MappedByteBuffer.force() throws IndexOutOfBoundsException
P4 JDK-8245121 (bf) XBuffer.put(Xbuffer src) can give unexpected result when storage overlaps
P4 JDK-8053479 (dc) DatagramChannel.read() throws exception instead of discarding data when buffer too small
P4 JDK-8239355 (dc) Initial value of SO_SNDBUF should allow sending large datagrams (macOS)
P4 JDK-8236184 (dc) IP_MULTICAST_* and IP_TOS socket options not effective
P4 JDK-8236925 (dc) Upgrade DatagramChannel socket adaptor to extend MulticastSocket
P4 JDK-8242292 (fs) FileSystems.getFileSystem(URI) should throw IAE if the URI scheme is null
P4 JDK-8241568 (fs) UserPrincipalLookupService.lookupXXX failure with IOE "Operation not permitted"
P4 JDK-4617266 (se spec) SelectionKey.OP_READ/OP_WRITE documentation errors
P4 JDK-8242006 (zipfs) Improve Zip FS FileChannel and SeekableByteChannel test coverage
P4 JDK-7143743 (zipfs) Potential memory leak with zip provider
P4 JDK-8229888 (zipfs) Updating an existing zip file does not preserve original permissions
P4 JDK-8246282 [REDO] JDK-8245121 (bf) XBuffer.put(Xbuffer src) can give unexpected result when storage overlaps
P4 JDK-8241305 Add protocol specific factory creation methods to SocketChannel and ServerSocketChannel
P4 JDK-8245623 Remove unused code in sun/nio/fs after Solaris removal
P4 JDK-8245619 Remove unused methods in UnixNativeDispatcher
P4 JDK-8236246 SelectorProvider support for creating a DatagramChannel that is not interruptible
P5 JDK-8241952 (fs) FileChannel.write​(ByteBuffer src, long position) does not check for the FileChannel being closed first
P5 JDK-8242356 (se) epoll Selector should use epoll_create1 instead of epoll_create
P5 JDK-8241883 (zipfs) SeekableByteChannel:close followed by SeekableByteChannel:close will throw an NPE

core-libs/java.nio.charsets

Priority Bug Summary
P3 JDK-8232161 Align some one-way conversion in MS950 charset with Windows
P3 JDK-8235834 IBM-943 charset encoder needs updating
P3 JDK-8242541 Small charset issues (ISO8859-16, x-eucJP-Open, x-IBM834 and x-IBM949C)
P4 JDK-8241311 Move some charset mapping tests from closed to open
P4 JDK-8239965 XMLEncoder/Test4625418.java fails due to "Error: Cp943 - can't read properly"

core-libs/java.rmi

Priority Bug Summary
P3 JDK-8241073 Pre-generated Stubs for javax.management, Activation, Naming
P3 JDK-8225319 Remove rmic from the set of supported tools
P3 JDK-8242462 Residual Cleanup of rmic removal
P4 JDK-8245068 Implement Deprecation of RMI Activation
P4 JDK-8244917 JEP 385: Deprecate RMI Activation for Removal
P4 JDK-8242382 test/jdk/TEST.groups cleanup of sun/tools/java
P5 JDK-6415694 Clarification in Javadoc for java.rmi.AlreadyBoundException

core-libs/java.text

Priority Bug Summary
P3 JDK-8243664 JavaDoc of CompactNumberFormat points to wrong enum
P3 JDK-8242337 javadoc typo in NumberFormat::setMinimumFractionDigits
P3 JDK-8227313 Support monetary grouping separator in DecimalFormat/DecimalFormatSymbols
P4 JDK-8235699 ArrayIndexOutOfBoundsException in CalendarBuilder.toString

core-libs/java.time

Priority Bug Summary
P2 JDK-8240626 Some of the java.time.chrono.Eras return empty display name for some styles and locales
P3 JDK-8243541 (tz) Upgrade Timezone Data to tzdata2020a
P3 JDK-8187987 Add a mechanism to configure custom variants in HijrahChronology
P4 JDK-8244245 localizedBy() should override localized values with default values
P4 JDK-8235238 Parsing a time string ignores any custom TimeZoneNameProvider
P4 JDK-8246662 Test java/time/test/java/time/format/TestUnicodeExtension.java failed on japanese locale.
P4 JDK-8239837 Typo in source code of ZoneOffsetTransitionRule leaking to Javadocs
P4 JDK-8239520 ValueRange.of(long, long, long) does not throw IAE on invalid inputs
P4 JDK-8236903 ZoneRules#getOffset throws DateTimeException for rules with last rules
P4 JDK-8239836 ZoneRules.of() doesn't check transitionList/standardOffsetTL arguments validity

core-libs/java.util

Priority Bug Summary
P1 JDK-8246183 Scanner/ScanTest.java fails due to SIGSEGV in StubRoutines::jshort_disjoint_arraycopy
P2 JDK-8249258 java/util/StringJoiner/StringJoinerTest.java failed due to OOM
P2 JDK-8246696 Test: java/util/StringJoiner/StringJoinerTest.java failing with OOM
P3 JDK-8230743 StringJoiner does not handle too large strings correctly
P3 JDK-8246697 Test: StringJoinerTest and related MergeTest failing with OOM
P4 JDK-8222241 Example in ServiceLoader API docs should have one provides directive
P4 JDK-8196334 Optimize UUID#fromString
P5 JDK-8244293 Remove outdated @apiNote in java.util.Objects

core-libs/java.util.jar

Priority Bug Summary
P3 JDK-8234466 Class loading deadlock involving X509Factory#commitEvent()
P3 JDK-8243254 Examine ZipFile slash optimization for non-ASCII compatible charsets
P3 JDK-8239351 Give more meaningful InternalError messages in Deflater.c
P4 JDK-8242842 Avoid reallocating name when checking for trailing slash in ZipFile.getEntryPos
P4 JDK-8193066 Avoid use of capturing lambdas in JarFile
P4 JDK-8242596 Improve JarFile.getEntry performance for multi-release jar files
P4 JDK-8242848 Improve performance of InflaterOutputStream.write()
P4 JDK-8240235 jdk.test.lib.util.JarUtils updates jar files incorrectly
P4 JDK-8243469 Lazily encode name in ZipFile.getEntryPos
P4 JDK-8211974 move test/jdk/lib/testlibrary/java/util/jar/*.java to top-level library or a local library
P4 JDK-8242959 Optimize ZipFile.getEntry by folding lookups for name and name+'/'
P4 JDK-8237508 Simplify JarFile.isInitializing
P4 JDK-8249097 test/lib/jdk/test/lib/util/JarBuilder.java has a bad copyright
P4 JDK-8246129 ZIP entries created for DOS epoch include local timezone metadata

core-libs/java.util.logging

Priority Bug Summary
P2 JDK-8245867 Logger/bundleLeak/BundleTest.java fails due to "OutOfMemoryError: Java heap space"
P3 JDK-8239013 java.util.logging.Logger catalog cache keeps strong references to ResourceBundles

core-libs/java.util.regex

Priority Bug Summary
P3 JDK-8241055 Regex Grapheme Matcher Performance Depends too much on Total Input Sequence Size
P3 JDK-8235812 Unicode linebreak with quantifier does not match valid input
P4 JDK-8214245 Case insensitive matching doesn't work correctly for some character classes
P4 JDK-8216332 Grapheme regex does not work with emoji sequences
P4 JDK-8237599 Greedy matching against supplementary chars fails to respect the region
P4 JDK-8235930 java.util.regex.PrintPattern does not print a link to the next node
P4 JDK-8246198 Minor typo injava/util/regex/Pattern.java
P4 JDK-8236034 Use optimized Ques node for curly {0,1} quantifier

core-libs/java.util.stream

Priority Bug Summary
P3 JDK-8238919 (doc) Broken code snippet in the java.util.stream package documentation
P4 JDK-8244624 Improve handling of JarFile META-INF resources
P4 JDK-8242281 IntStream.html#reduce doc should not mention average

core-libs/java.util:collections

Priority Bug Summary
P4 JDK-8046362 IdentityHashMap.hash comments should be clarified
P4 JDK-8236641 Improve Set.of(...).iterator() warmup characteristics
P4 JDK-8242327 List spec should state that unmodifiable lists implement RandomAccess
P4 JDK-8161558 ListIterator should not discard cause on exception
P4 JDK-8243655 Map.replace javadoc code snippet typo
P4 JDK-8236850 Operations on constant List/Set.of(element) instances does not consistently constant fold
P4 JDK-8245677 Optimize lookups in empty HashMaps
P4 JDK-8238684 Override getOrDefault in immutable Map implementations
P4 JDK-8176894 Provide specialized implementation for default methods putIfAbsent, computeIfAbsent, computeIfPresent, compute, merge in TreeMap

core-libs/java.util:i18n

Priority Bug Summary
P3 JDK-8242283 Can't start JVM when java home path includes non-ASCII character
P3 JDK-8236548 Localized time zone name inconsistency between English and other locales
P3 JDK-8239480 Update CLDR to version 37.0
P3 JDK-8241082 Update IANA Language Subtag Registry to Version 2020-03-16
P4 JDK-8234347 "Turkey" meta time zone does not generate composed localized names
P4 JDK-8174270 Consolidate ICU sources in one location
P4 JDK-8245241 Incorrect locale provider preference is not logged
P4 JDK-8246721 java/util/Locale/LocaleProvidersRun.java failed on Windows platforms.
P4 JDK-8244459 Optimize the hash map size in LocaleProviderAdapters
P4 JDK-8244767 Potential non-terminated string in getEncodingInternal() on Windows
P4 JDK-8244152 Remove unnecessary hash map resize in LocaleProviderAdapters
P4 JDK-8238203 Return value of GetUserDefaultUILanguage() should be handled as LANGID
P4 JDK-8242010 Update IANA Language Subtag Registry to Version 2020-04-01
P4 JDK-8243504 Update ICU4J to version 67.1

core-libs/javax.lang.model

Priority Bug Summary
P3 JDK-8227044 javax.lang.model for sealed classes
P4 JDK-8246368 Add override for return tag of Modifier::toString
P4 JDK-8244673 Add periods to SourceVersion.isName javadoc
P4 JDK-8235497 Add SourceVersion.RELEASE_15
P4 JDK-8240130 Improve and update discussion of visitor evolution warnings
P4 JDK-8239478 Make specification of SourceVersion.isName explicit for dotted names
P4 JDK-8225495 Note whether returned annotations are declaration annotations or type annotations
P4 JDK-8193553 Provide better guidance on using javax.lang.model visitors
P4 JDK-8239092 Provide explicit specification for getKind methods of javax.lang.model
P4 JDK-8246290 Refine specification of javax.lang.model.element.Modifier::toString
P4 JDK-8245146 Update description of SourceVersion.RELEASE_15 with text blocks

core-libs/javax.naming

Priority Bug Summary
P3 JDK-8237834 com/sun/jndi/ldap/LdapDnsProviderTest.java failing with LDAP response read timeout
P3 JDK-8223260 NamingManager should cache InitialContextFactory
P4 JDK-8241130 com.sun.jndi.ldap.EventSupport.removeDeadNotifier: java.lang.NullPointerException
P4 JDK-8062947 Fix exception message to correctly represent LDAP connection failure
P4 JDK-7006496 Use modern Windows API to retrieve OS DNS servers

core-libs/javax.sql

Priority Bug Summary
P2 JDK-8235961 Default javax.sql.rowset.spi.SyncResolver impl returned by SyncProviderException throws unspecified NPE, UOE

core-libs/jdk.nashorn

Priority Bug Summary
P2 JDK-8247956 remove scripts under bin/nashorn and doc/nashorn/source
P3 JDK-8241749 Remove the Nashorn JavaScript Engine

core-svc/debugger

Priority Bug Summary
P2 JDK-8244703 "platform encoding not initialized" exceptions with debugger, JNI
P3 JDK-8247784 Bad link causes invalid documentation
P3 JDK-8236913 debug agent's jdwp command logging should include the command set name and command name
P3 JDK-8196450 Deprecate JDWP/JDI canUnrestrictedlyRedefineClasses to match JVM TI capabilities
P3 JDK-8240142 Fix copyright in ThreadGroupReferenceImpl.h
P3 JDK-8240902 JDI shared memory connector can use already closed Handles
P3 JDK-8241807 JDWP needs update for hidden classes
P3 JDK-8234935 JdwpListenTest.java and JdwpAttachTest.java getting bind failures on Windows 2016 hosts
P3 JDK-8247958 minor HTML errors in com.sun.jdi
P3 JDK-8241958 Slow ClassLoaderReferenceImpl.findType
P3 JDK-8241214 Test debugging of hidden classes using jdb
P4 JDK-8239856 [ntintel] asserts about copying unaligned array element
P4 JDK-8242241 add assert to ClassUnloadEventImpl::className
P4 JDK-8241530 com/sun/jdi tests fail due to network issues on OSX 10.15
P4 JDK-8241080 Consolidate signature parsing code in serviceability tools
P4 JDK-8227269 Slow class loading when running with JDWP
P4 JDK-8243437 use reproducible random in :vmTestbase_nsk_jdi
P4 JDK-8239055 Wrong implementation of VMState.hasListener
P4 JDK-8241750 x86_32 build failure after JDK-8227269

core-svc/java.lang.instrument

Priority Bug Summary
P4 JDK-8234968 check calloc rv in libinstrument InvocationAdapter
P4 JDK-8243012 Fix issues in j.l.i package info
P4 JDK-8238602 remove obsolete functions from libinstrument/FileSystemSupport_md.c

core-svc/java.lang.management

Priority Bug Summary
P3 JDK-8240957 Clarify BadAttributeValueExpException readObject method
P4 JDK-8248061 bad reference in @throws in HotSpotDiagnosticMXBean
P4 JDK-8242430 Correct links in javadoc of OperatingSystemMXBean
P4 JDK-8229829 java/lang/management/ThreadMXBean/Locks.java fails with java.lang.RuntimeException: Thread WaitingThread is at WAITING state but is expected to be in Thread.State = WAITING
P4 JDK-8242480 Negative value may be returned by getFreeSwapSpaceSize() in the docker
P4 JDK-8235681 Remove unnecessary workarounds in UnixOperatingSystem.c
P4 JDK-8232622 Technical debt in BadAttributeValueExpException
P4 JDK-8243436 use reproducible random in :vmTestbase_nsk_monitoring

core-svc/javax.management

Priority Bug Summary
P3 JDK-8242239 [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same
P3 JDK-8247894 Invalid @see in java.management
P3 JDK-8213222 remove RMIConnectorServer.CREDENTIAL_TYPES
P4 JDK-8234484 Add ability to configure third port for remote JMX

core-svc/tools

Priority Bug Summary
P2 JDK-8240881 [BACKOUT] 8222489 jcmd VM.system_properties gives unusable paths on Windows
P3 JDK-8196729 Add jstatd option to specify RMI connector port
P3 JDK-8222489 jcmd VM.system_properties gives unusable paths on Windows
P3 JDK-8236968 jmap -clstats fails to work after JDK-8232759
P3 JDK-8238710 LingeredApp doesn't log stdout/stderr if exits with non-zero code
P3 JDK-8235211 serviceability/attach/RemovingUnixDomainSocketTest.java fails with AttachNotSupportedException: Unable to open socket file
P3 JDK-8242282 Test sun/tools/jps/TestJps.java fails after JDK-8237572
P3 JDK-8236917 TestInstanceKlassSize.java fails with "The size computed by SA for java.lang.Object does not match"
P4 JDK-8237354 Add option to jcmd to write a gzipped heap dump
P4 JDK-8237111 LingeredApp should be started with getTestJavaOpts
P4 JDK-8232759 Remove GC.class_stats
P4 JDK-8240711 TestJstatdPort.java failed due to "ExportException: Port already in use:"

deploy/packager

Priority Bug Summary
P3 JDK-8243648 Windows 32bit compile error src/jdk.incubator.jpackage/windows/native/libjpackage/VersionInfo.cpp

docs/guides

Priority Bug Summary
P3 JDK-8168868 Add additional admin-level documentation for trusted certs not being "disabled"
P3 JDK-8245656 Document jpackager options for user-defined jlink options
P3 JDK-8245852 Document New System Properties to configure the TLS signature schemes
P3 JDK-8245848 Document the certificate_authorities extension in JSSE Reference Guides
P3 JDK-8242389 Enhance jpackage documentation of mac signing
P3 JDK-8246035 java scripting guide's use nashorn scripts
P3 JDK-8242409 Update Kerberos GSS-API mechanism page to include the "canonicalize" setting
P3 JDK-8250522 Wrong property name in security docs: jsse.enableFFDHEExtension
P4 JDK-8241328 Need to update security providers guide for SunJCE provider for new support
P4 JDK-8265717 Update Java Virtual Machine Guide about CDS support for ZGC

globalization/translation

Priority Bug Summary
P2 JDK-8238377 JDK 14 L10n resource file update - msg drop 20
P3 JDK-8249086 JDK 15 L10n resource file update - msg drop 10

hotspot/compiler

Priority Bug Summary
P1 JDK-8240830 [BACKOUT] 8240195: some jaotc failures of fastdebug build with specific flags
P1 JDK-8248597 [Graal] api/java_security/SignatureSpi/DelegationTests.html fails with Method "javasoft.sqe.tests.api.java.security.SignatureSpi.JCKSignatureSpi.clear" doesn't exist.
P1 JDK-8238896 Massive x86_32 crashes after JDK-7175279 (Don't use x87 FPU on x86-64)
P2 JDK-8248822 8 vm/classfmt/atr_ann/atr_rtm_annot007/atr_rtm_annot00709 tests fail w/ AOT
P2 JDK-8247832 [Graal] Many Javafuzzer tests failures with Graal, due to unexpected results, after last update JDK-8243380
P2 JDK-8248598 [Graal] Several testcases from applications/jcstress/acqrel.java fails with forbidden state
P2 JDK-8230015 [instruction selector] generic vector operands support.
P2 JDK-8245047 [PPC64] C2: ReverseBytes + Load always match to unordered Load (acquire semantics missing)
P2 JDK-8231118 ARM32: Math tests failures
P2 JDK-8239878 Bug in PrintEliminateAllocations code causes TestClhsdbJstackLock.java to fail
P2 JDK-8250609 C2 crash in IfNode::fold_compares
P2 JDK-8241041 C2: "assert((Value(phase) == t) || (t != TypeInt::CC_GT && t != TypeInt::CC_EQ)) failed: missing Value() optimization" still happens after fix for 8239335
P2 JDK-8239335 C2: assert((Value(phase) == t) || (t != TypeInt::CC_GT && t != TypeInt::CC_EQ)) failed: missing Value() optimization
P2 JDK-8240335 C2: assert(found_sfpt) failed: no node in loop that's not input to safepoint
P2 JDK-8237859 C2: Crash when loads float above range check
P2 JDK-8242895 failed: sanity at src/hotspot/share/opto/escape.cpp:2361
P2 JDK-8241074 JDK-8240363 broke the build on AArch64
P2 JDK-8240576 JVM crashes after transformation in C2 IdealLoopTree::merge_many_backedges
P2 JDK-8244407 JVM crashes after transformation in C2 IdealLoopTree::split_fall_in
P2 JDK-8249880 JVMCI calling register_nmethod without CodeCache lock
P2 JDK-8240227 Loop predicates should be copied to unswitched loops
P2 JDK-8241900 Loop unswitching may cause dependence on null check to be lost
P2 JDK-8241556 Memory leak if -XX:CompileCommand is set
P2 JDK-8246027 Minimal fastdebug build broken after JDK-8245801
P2 JDK-8247502 PhaseStringOpts crashes while optimising effectively dead code
P2 JDK-8239569 PublicMethodsTest.java failed due to NPE in java.base/java.nio.file.FileSystems.getFileSystem(FileSystems.java:230)
P2 JDK-8239367 RunThese30M.java failed due to "assert(false) failed: graph should be schedulable"
P2 JDK-8229495 SIGILL in C2 generated OSR compilation
P2 JDK-8243670 Unexpected test result caused by C2 MergeMemNode::Ideal
P2 JDK-8242502 UnexpectedDeoptimizationTest.java failed "assert(phase->type(obj)->isa_oopptr()) failed: only for oop input"
P2 JDK-8242073 x86_32 build failure after JDK-8241040
P2 JDK-8238909 x86_32 fails gtest:power_of_2
P2 JDK-8238723 yank_alloc_node must remove membar
P3 JDK-8245714 "Bad graph detected in build_loop_late" when loads are pinned on loop limit check uncommon branch
P3 JDK-8247350 [aarch64] assert(false) failed: wrong size of mach node
P3 JDK-8246051 [aarch64] SIGBUS by unaligned Unsafe compare_and_swap
P3 JDK-8240794 [BACKOUT] 8238384 CTW: C2 compilation fails with "assert(store != load->find_exact_control(load->in(0))) failed: dependence cycle found"
P3 JDK-8235673 [C1, C2] Split inlining control flags
P3 JDK-8241802 [Graal] compiler/loopopts/TestLogSum.java timed out
P3 JDK-8247246 [JVMCI] `ResolvedJavaType.getDeclaredMethod()` can throw NoClassDefFoundError.
P3 JDK-8240831 [JVMCI] Export missing vmStructs entries used by JVMCI compilers
P3 JDK-8247992 [JVMCI] HotSpotNmethod.executeVarargs can try execute a zombie nmethod
P3 JDK-8240976 [JVMCI] MethodProfileWidth flag is broken
P3 JDK-8240795 [REDO] 8238384 CTW: C2 compilation fails with "assert(store != load->find_exact_control(load->in(0))) failed: dependence cycle found"
P3 JDK-8240854 [REDO] some jaotc failures of fastdebug build with specific flags
P3 JDK-8247200 AArch64: assert((unsigned)fpargs < 32)
P3 JDK-8244164 AArch64: jaotc generates incorrect code for compressed OOPs with non-zero heap base
P3 JDK-8248845 AArch64: stack corruption after spilling vector register
P3 JDK-8229351 AArch64: the const STUB_THRESHOLD in macroAssembler_aarch64.cpp needs to be tuned
P3 JDK-8167065 Add intrinsic support for double precision shifting on x86_64
P3 JDK-8219607 Add support in Graal and AOT for hidden class
P3 JDK-8230402 Allocation of compile task fails with assert: "Leaking compilation tasks?"
P3 JDK-8237086 assert(is_MachReturn()) running CTW with fix for JDK-8231291
P3 JDK-8240905 assert(mem == (Node*)1 || mem == mem2) failed: multiple Memories being matched at once?
P3 JDK-8247763 assert(outer->outcnt() == 2) failed: 'only phis' failure in LoopNode::verify_strip_mined()
P3 JDK-8239083 C1 assert(known_holder == NULL || (known_holder->is_instance_klass() && (!known_holder->is_interface() || ((ciInstanceKlass*)known_holder)->has_nonstatic_concrete_methods())), "should be non-static concrete method");
P3 JDK-8245051 c1 is broken if it is compiled by gcc without -fno-lifetime-dse
P3 JDK-8236179 C1 register allocation failure with T_ADDRESS
P3 JDK-8237950 C2 compilation fails with "Live Node limit exceeded limit" during ConvI2L::Ideal optimization
P3 JDK-8234605 C2 failed "assert(C->live_nodes() - live_at_begin <= 2 * _nodes_required) failed: Bad node estimate: actual = 208 >> request = 101"
P3 JDK-8239142 C2's UseUniqueSubclasses optimization is broken for array accesses
P3 JDK-8242491 C2: assert(v2->bottom_type() == vt) failed: mismatch when creating MacroLogicV
P3 JDK-8241436 C2: Factor out C2-specific code from MacroAssembler
P3 JDK-8238690 C2: Handle vector shifts by constant and non-constant scalar uniformly
P3 JDK-8235824 C2: Merge AD instructions for AddReductionV and MulReductionV nodes
P3 JDK-8235825 C2: Merge AD instructions for Replicate nodes
P3 JDK-8236181 C2: Remove useless step_over_gc_barrier() in int->bool conversion
P3 JDK-8239008 C2: Simplify Replicate support for sub-word types on x86
P3 JDK-8244660 Code cache sweeper heuristics is broken
P3 JDK-8238356 CodeHeap::blob_count() overestimates the number of blobs
P3 JDK-8248410 Correct Fix for 8236647: java/lang/invoke/CallSiteTest.java failed with InvocationTargetException in Graal mode
P3 JDK-8235385 Crash on aarch64 JDK due to long offset
P3 JDK-8244719 CTW: C2 compilation fails with "assert(!VerifyHashTableKeys || _hash_lock == 0) failed: remove node from hash table before modifying it"
P3 JDK-8244724 CTW: C2 compilation fails with "Live Node limit exceeded limit"
P3 JDK-8237945 CTW: C2 compilation fails with assert(just_allocated_object(alloc_ctl) == ptr) failed: most recent allo
P3 JDK-7175279 Don't use x87 FPU on x86-64
P3 JDK-8244278 Excessive code cache flushes and sweeps
P3 JDK-8244086 Following 8241492, strip mined loop may run extra iterations
P3 JDK-8244852 GraalVM native-image fails after JDK-8238048 change
P3 JDK-8239001 Hotspot build broken on linux-sparc after 8238281
P3 JDK-8246805 Incorrect copyright header in TestInvalidTieredStopAtLevel.java
P3 JDK-8248570 Incorrect copyright header in TestUnsafeUnalignedSwap.java
P3 JDK-8236647 java/lang/invoke/CallSiteTest.java failed with InvocationTargetException in Graal mode
P3 JDK-8239852 java/util/concurrent tests fail with -XX:+VerifyGraphEdges: assert(!VerifyGraphEdges) failed: verification should have failed
P3 JDK-8239477 jdk/jfr/jcmd/TestJcmdStartStopDefault.java fails -XX:+VerifyOops with "verify_oop: rsi: broken oop"
P3 JDK-8237045 JVM uses excessive memory with -XX:+EnableJVMCI -XX:JVMCICounterSize=2147483648
P3 JDK-8245128 Kitchensink fails with: assert(destination == (address)-1 || destination == entry) failed: b) MT-unsafe modification of inline cache
P3 JDK-8136414 Large performance penalty declaring a method strictfp on strict-only platforms
P3 JDK-8238681 Make -XX:UseSSE flag x86-specific
P3 JDK-8240676 Meet not symmetric failure when running lucene on jdk8
P3 JDK-8242108 Performance regression after fix for JDK-8229496
P3 JDK-8238765 PhaseCFG::schedule_pinned_nodes cannot handle precedence edges from unmatched CFG nodes correctly
P3 JDK-8237787 rewrite vmTestbase/vm/compiler/CodeCacheInfo* from shell to java
P3 JDK-8241997 Scalar replacement of cloned array is broken after JDK-8238759
P3 JDK-8237007 Shenandoah: assert(_base == Tuple) failure during C2 compilation
P3 JDK-8241675 Shenandoah: assert(n->outcnt() > 0) at shenandoahSupport.cpp:2858 with java/util/Collections/FindSubList.java
P3 JDK-8236759 ShouldNotReachHere in PhaseIdealLoop::verify_strip_mined_scheduling
P3 JDK-8237375 SimpleThresholdPolicy misses CounterDecay timestamp initialization
P3 JDK-8240195 some jaotc failures of fastdebug build with specific flags
P3 JDK-8236709 struct SwitchRange in HS violates C++ One Definition Rule
P3 JDK-8238438 SuperWord::co_locate_pack picks memory state of first instead of last load
P3 JDK-8241040 Support for AVX-512 Ternary Logic Instruction
P3 JDK-8240693 Sweeper should not examine dying metadata in is_unloading() nmethod during static call stub cleaning
P3 JDK-8246453 TestClone crashes with "all collected exceptions must come from the same place"
P3 JDK-8235332 TestInstanceCloneAsLoadsStores.java fails with -XX:+StressGCM
P3 JDK-8243380 Update Graal
P3 JDK-8247798 Update man pages for inline flags
P3 JDK-8246381 VM crashes with "Current BasicObjectLock* below than low_mark"
P3 JDK-8237953 vmTestbase/jit/tiered/Test.java failure after JDK-8237798
P3 JDK-8238696 x86: Enumerate all detected CPU features in VM_Version feature string
P4 JDK-8241232 -XX:+BootstrapJVMCI is not compatible with TieredStopAtLevel < CompLevel_full_optimization
P4 JDK-8244170 [aarch64] correct instruction typo for dcps1/2/3
P4 JDK-8227647 [Graal] Test8009761.java fails due to "RuntimeException: static java.lang.Object compiler.uncommontrap.Test8009761.m3(boolean,boolean) not compiled"
P4 JDK-8193210 [JVMCI/Graal] add JFR compiler phase/inlining events
P4 JDK-8241458 [JVMCI] add mark value to expose CodeOffsets::Frame_Complete
P4 JDK-8240538 [JVMCI] add test for JVMCI ConstantPool class
P4 JDK-8240610 [JVMCI] Export VMVersion::_has_intel_jcc_erratum to JVMCI compiler
P4 JDK-8238758 [JVMCI] fix JVMCI jtreg events tests to work with GraalVM
P4 JDK-8238190 [JVMCI] Fix single implementor speculation for diamond shapes.
P4 JDK-8236285 [JVMCI] improve TranslatedException traces
P4 JDK-8242357 [JVMCI] Incorrect use of JVMCI_CHECK_ on return statement
P4 JDK-8231756 [JVMCI] need support for deoptimizing virtual byte arrays encoding non-byte primitives
P4 JDK-8230290 [JVMCI] Remove unused API entry points
P4 JDK-8239456 [win][x86] vtable stub generation: assert failure (code size estimate)
P4 JDK-8239931 [win][x86] vtable stub generation: assert failure (code size estimate) follow-up
P4 JDK-8243620 a few compiler/jvmci tests can be run in driver mode
P4 JDK-8241091 AArch64: "bad AD file" with VM option "-XX:-UsePopCountInstruction"
P4 JDK-8241475 AArch64: Add missing support for PopCountVI node
P4 JDK-8243597 AArch64: Add support for integer vector abs
P4 JDK-8243240 AArch64: Add support for MulVB
P4 JDK-8243155 AArch64: Add support for SqrtVF
P4 JDK-8239549 AArch64: Backend support for MulAddVS2VI node
P4 JDK-8242482 AArch64: Change parameter names of reduction operations to make code clear
P4 JDK-8241911 AArch64: Fix a potential issue about register allocation effect rule in reduce_add2I
P4 JDK-8241482 AArch64: Fix a potential issue after JDK-8239549
P4 JDK-8242070 AArch64: Fix a typo introduced by JDK-8238690
P4 JDK-8233743 AArch64: Make r27 conditionally allocatable
P4 JDK-8230591 AArch64: Missing intrinsics for Math.ceil, floor, rint
P4 JDK-8240353 AArch64: missing support for -XX:+ExtendedDTraceProbes in C1
P4 JDK-8243339 AArch64: Obsolete UseBarriersForVolatile option
P4 JDK-8245986 AArch64: Provide information when hitting a HaltNode
P4 JDK-8242449 AArch64: r27 can be allocated in CompressedOops mode
P4 JDK-8241587 Aarch64: remove x86 specifics from os_linux.cpp/hpp/inline.hpp
P4 JDK-8234228 AArch64: Some temp vars in string_compare intrinsics for processing the last 4 chars (LU/UL) are no use
P4 JDK-8237524 AArch64: String.compareTo() may return incorrect result
P4 JDK-8237724 Add org.graalvm.compiler.asm.amd64 to the list of packages to be processed by the options annotation processor
P4 JDK-8243622 all actions in compiler/aot/fingerprint/SelfChangedCDS.java can be run in driver mode
P4 JDK-8244186 assertion failure test/jdk/javax/net/ssl/DTLS/RespondToRetransmit.java
P4 JDK-8242429 Better implementation for signed extract
P4 JDK-8236721 C2 should better optimize not-equal integer comparisons
P4 JDK-8238756 C2: assert(((n) == __null || !VerifyIterativeGVN || !((n)->is_dead()))) failed: can not use dead node
P4 JDK-8238811 C2: assert(i >= req() || i == 0 || is_Region() || is_Phi()) with -XX:+VerifyGraphEdges
P4 JDK-8239009 C2: Don't use PSHUF to load scalars from memory on x86
P4 JDK-8245158 C2: Enable SLP for some manually unrolled loops
P4 JDK-8231291 C2: loop opts before EA should maximally unroll loops
P4 JDK-8244504 C2: refactor counted loop code in preparation for long counted loop
P4 JDK-8242492 C2: Remove Matcher::vector_shift_count_ideal_reg()
P4 JDK-8238680 C2: Remove redundant AD instructions for Replicate nodes
P4 JDK-8238683 C2: Remove Use24BitFP and Use24BitFPMode develop flags
P4 JDK-8242289 C2: Support platform-specific node cloning in Matcher
P4 JDK-8238691 C2: turn subtype check into macro node
P4 JDK-8236228 clean up BarrierSet headers in c1_LIRAssembler
P4 JDK-8249019 clean up FileInstaller $test.src $cwd in vmTestbase_vm_compiler tests
P4 JDK-8249018 clean up FileInstaller $test.src $cwd in vmTestbase_vm_mlvm tests
P4 JDK-8238759 Clones should always keep the base pointer
P4 JDK-8248265 compiler/ciReplay tests fail with AOT compiled java.base
P4 JDK-8243619 compiler/codecache/CheckSegmentedCodeCache.java test misses -version
P4 JDK-8243932 compiler/codecache/cli/printcodecache/TestPrintCodeCacheOption.java test can use driver mode
P4 JDK-8243617 compiler/onSpinWait/TestOnSpinWaitC1.java test uses wrong class
P4 JDK-8243618 compiler/rtm/cli tests can be run w/o WhiteBox
P4 JDK-8245512 CRC32 optimization using AVX512 instructions
P4 JDK-8238366 CTW runner closes standard output on exit
P4 JDK-8237949 CTW: C1 compilation fails with "too many stack slots used"
P4 JDK-8238178 CTW: C1 compilation fails with assert(sux->loop_depth() != block->loop_depth() || sux->loop_index() == block->loop_index() || loop_through_xhandler) failed: Loop index has to be same
P4 JDK-8237894 CTW: C1 compilation fails with assert(x->type()->tag() == f->type()->tag()) failed: should have same type
P4 JDK-8238385 CTW: C2 (Shenandoah) compilation fails with "Range check dependent CastII node was not removed"
P4 JDK-8244721 CTW: C2 (Shenandoah) compilation fails with "unexpected infinite loop graph shape"
P4 JDK-8238153 CTW: C2 (Shenandoah) compilation fails with "Unknown node in get_load_addr: CreateEx"
P4 JDK-8238384 CTW: C2 compilation fails with "assert(store != load->find_exact_control(load->in(0))) failed: dependence cycle found"
P4 JDK-8237951 CTW: C2 compilation fails with "malformed control flow"
P4 JDK-8241365 Define Unique_Node_List::contains() to prevent usage by mistake
P4 JDK-8240669 Devirtualize Relocation::type
P4 JDK-8234160 Enable optimized mitigation for Intel jcc erratum in C2
P4 JDK-8240248 Extend superword reduction optimizations for x86
P4 JDK-8242796 Fix client build failure
P4 JDK-8244819 hsdis does not compile with binutils 2.34+
P4 JDK-8240220 IdealLoopTree::dump_head predicate printing is broken
P4 JDK-8237581 Improve allocation expansion
P4 JDK-8242793 Incorrect copyright header in ContinuousCallSiteTargetChange.java
P4 JDK-8239500 jittester shouldn't use non-deterministic System methods
P4 JDK-8168304 Make all of DependencyContext_test available in product mode
P4 JDK-8241438 Move IntelJccErratum mitigation code to platform-specific code
P4 JDK-8245864 Obsolete BranchOnRegister
P4 JDK-8246023 Obsolete LIRFillDelaySlot
P4 JDK-8240528 OopMap cleanup
P4 JDK-8151030 PPC64: AllocatePrefetchStyle=4 is out of range
P4 JDK-8241874 PPC64: Improve performance of Long.reverseBytes() and Integer.reverseBytes() on Power9
P4 JDK-8245505 Prelink j.l.ref.Reference when loading AOT library
P4 JDK-8230552 Provide information when hitting a HaltNode for architectures other than x86
P4 JDK-8240370 Provide Intel JCC Erratum opt-out
P4 JDK-8240363 Refactor Compile::Output() to its own Phase
P4 JDK-8242090 Remove dead code from c1_LIR
P4 JDK-8244658 Remove dead code in code cache sweeper
P4 JDK-8022574 remove HaltNode code after uncommon trap calls
P4 JDK-8244433 Remove saving of RSP in Assembler::pusha_uncached()
P4 JDK-8235995 Remove src/jdk.internal.vm.compiler/.mx.graal directory
P4 JDK-8203883 Remove State from InvocationCounters
P4 JDK-8241122 Remove unimplemented InlineTree constructor definition from parse.hpp
P4 JDK-8245957 Remove unused LIR_OpBranch::type after SPARC port removal
P4 JDK-8241909 Remove useless code cache lookup in frame::patch_pc
P4 JDK-8237800 rewrite vmTestbase/jit/escape/LockCoarsening from shell to java
P4 JDK-8237798 rewrite vmTestbase/jit/tiered from shell to java
P4 JDK-8240070 Shenandoah: remove obsolete ShenandoahCommonGCStateLoads
P4 JDK-8241070 Shenandoah: remove unused local variables in C2 support
P4 JDK-8244207 Simplify usage of Compile::print_method() when debugging with gdb and enable its use with rr
P4 JDK-8245801 StressRecompilation triggers assert "redundunt OSR recompilation detected. memory leak in CodeCache!"
P4 JDK-8241492 Strip mining not working for test/hotspot/jtreg/compiler/c2/Test6850611.java
P4 JDK-8239072 subtype check macro node causes node budget to be exhausted
P4 JDK-8246153 TestEliminateArrayCopy fails with -XX:+StressReflectiveCode
P4 JDK-8241986 The 'java' man page erroneously refers to XEND when it should refer XTEST
P4 JDK-8241234 Unify monitor enter/exit runtime entries.
P4 JDK-8249622 use 8249621 to ignore 8 jvmci tests
P4 JDK-8240829 Use a fast O(1) algorithm for exact_log2
P4 JDK-8240223 Use consistent predicate order in and with PhaseIdealLoop::find_predicate
P4 JDK-8243428 use reproducible random in :vmTestbase_vm_compiler
P4 JDK-8243427 use reproducible random in :vmTestbase_vm_mlvm
P4 JDK-8242310 use reproducible random in hotspot compiler tests
P4 JDK-8243621 use SkippedException in compiler/jsr292/MHInlineTest.java test
P4 JDK-8249000 vm.gc.X should take selected JIT into account
P4 JDK-8237497 vmStructs_jvmci.cpp does not check that the correct field type is specified
P4 JDK-8238278 vmTestbase/vm/compiler/CodeCacheInfo/Test.java failure after JDK-8237787
P4 JDK-8241319 WB_GetCodeBlob doesn't have ResourceMark
P4 JDK-8241433 x86: Add VBMI CPU feature detection
P4 JDK-8241434 x86: Fix Assembler::emit_operand asserts for XMM registers
P4 JDK-8241597 x86: Remove MMX support
P4 JDK-8239110 Zero VM build fails after JDK-8203883
P4 JDK-8240846 Zero VM is broken on x86 after JDK-8238681: UseSSE not defined
P5 JDK-8191930 [Graal] emits unparseable XML into compile log
P5 JDK-8239069 C2: SIGSEGV in IdealGraphPrinter::walk_nodes due to C->root() being NULL
P5 JDK-8241595 Fix missing debug_orig information in Ideal Graph Visualizer
P5 JDK-8238863 Refactor out static initialization from Dict constructors
P5 JDK-8244182 Use root node as default for find_node when called from debugger

hotspot/gc

Priority Bug Summary
P1 JDK-8248048 ZGC: AArch64: SIGILL in load barrier register spilling
P1 JDK-8248388 ZGC: Load barrier incorrectly elided in jdk/java/text/Format/DateFormat/SDFTCKZoneNamesTest.java
P2 JDK-8236226 fix merge error in src/hotspot/share/gc/z/zRootsIterator.cpp
P2 JDK-8243961 ForceNUMA and only one available NUMA node fails assertion on Windows
P2 JDK-8242459 ForceNUMA and only one available NUMA node hits a guarantee
P2 JDK-8242216 ObjectSampler::weak_oops_do() should not trigger barrier
P2 JDK-8228991 Obsolete -XX:UseAdaptiveGCBoundary
P2 JDK-8244416 Remove incorrect assert during inline cache cleaning
P2 JDK-8215297 Remove ParallelTaskTerminator
P2 JDK-8237632 Shenandoah: accept NULL fwdptr to cooperate with JVMTI and JFR
P2 JDK-8237837 Shenandoah: assert(mem == __null) failed: only one safepoint
P2 JDK-8237874 Shenandoah: Backout JDK-8234399
P2 JDK-8237821 Shenandoah: build broken after JDK-8237637 (Remove dubious type conversions from oop)
P2 JDK-8238851 Shenandoah: C1: Resolve into registers of correct type
P2 JDK-8244663 Shenandoah: C2 assertion fails in Matcher::collect_null_checks
P2 JDK-8248725 Shenandoah: Claim verifier thread roots for parallel processing
P2 JDK-8247670 Shenandoah: deadlock during class unloading OOME
P2 JDK-8241081 Shenandoah: Do not modify update-watermark concurrently
P2 JDK-8236815 Shenandoah: Fix weak roots in final Traversal GC phase
P2 JDK-8247560 Shenandoah: heap iteration holds root locks all the time
P2 JDK-8250588 Shenandoah: LRB needs to save/restore fp registers for runtime call
P2 JDK-8237780 Shenandoah: More reliable nmethod verification
P2 JDK-8247310 Shenandoah: pacer should not affect interrupt status
P2 JDK-8236981 Shenandoah: Remove ShenandoahTraversalUpdateRefsClosure
P2 JDK-8239926 Shenandoah: Shenandoah needs to mark nmethod's metadata
P2 JDK-8245773 Shenandoah: Windows assertion failure after JDK-8245464
P2 JDK-8247474 Shenandoah: Windows build warning after JDK-8247310
P2 JDK-8245942 Shenandoah: x86_32 builds fail after JDK-8245594
P2 JDK-8245000 Windows GDI functions don't support large pages
P2 JDK-8245002 Windows GDI functions don't support NUMA interleaving
P2 JDK-8245106 ZGC: Fix incorrect setup when using -XX:+UseTransparentHugePages
P3 JDK-8242448 Change HeapRegionManager::guarantee_contiguous_range to be assert_contiguous_range
P3 JDK-8231779 crash HeapWord*ParallelScavengeHeap::failed_mem_allocate
P3 JDK-8247824 CTW: C2 (Shenandoah) compilation fails with SEGV in SBC2Support::pin_and_expand
P3 JDK-8241670 Enhance heap region size ergonomics to improve OOTB performance
P3 JDK-8240745 Implementation: JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production)
P3 JDK-8209683 JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production)
P3 JDK-8139652 Mutator refinement processing should take the oldest dirty card buffer
P3 JDK-8235860 Obsolete the UseParallelOldGC option
P3 JDK-8240589 OtherRegionsTable::_num_occupied not updated correctly
P3 JDK-8241765 Shenandoah: AARCH64 need to save/restore call clobbered registers before calling keepalive barrier
P3 JDK-8243200 Shenandoah: Allow concurrent nmethod iteration
P3 JDK-8236681 Shenandoah: Disable concurrent class unloading flag if no class unloading for the GC cycle
P3 JDK-8244821 Shenandoah: disarmed_value is initialized at wrong place
P3 JDK-8234974 Shenandoah: Do concurrent roots even when no evacuation is necessary
P3 JDK-8241793 Shenandoah: Enable concurrent class unloading for aarch64
P3 JDK-8242107 Shenandoah: Fix aarch64 build after JDK-8242082
P3 JDK-8249560 Shenandoah: Fix racy GC request handling
P3 JDK-8244551 Shenandoah: Fix racy update of update_watermark
P3 JDK-8246162 Shenandoah: full GC does not mark code roots when class unloading is off
P3 JDK-8237963 Shenandoah: Heap iteration should use concurrent version of string dedup roots
P3 JDK-8235842 Shenandoah: Implement native LRB for narrow oop
P3 JDK-8245961 Shenandoah: move some root marking to concurrent phase
P3 JDK-8245288 Shenandoah: move up ShenandoahEvacOOM scope for code root processing during concurrent class unloading
P3 JDK-8247358 Shenandoah: reconsider free budget slice for marking
P3 JDK-8243323 Shenandoah: Recycle immediate garbage before concurrent class unloading
P3 JDK-8236732 Shenandoah: Stricter placement for oom-evac scopes
P3 JDK-8246593 Shenandoah: string dedup roots should be processed during concurrent weak roots phase
P3 JDK-8245240 Shenandoah: support nesting evacuation OOM scope
P3 JDK-8244291 Test: gc/z/TestGarbageCollectorMXBean.java failed: "unexpected cycles"
P3 JDK-8214277 Use merged G1ArchiveRegionMap for open and closed archive heap regions
P3 JDK-8240679 ZGC GarbageCollectorMXBean reports inaccurate post GC heap size for ZHeap pool
P3 JDK-8246045 ZGC: Fix ZDirector::rule_high_usage() calculation
P3 JDK-8241603 ZGC: java/lang/management/MemoryMXBean/MemoryTestZGC.sh crashes on macOS
P4 JDK-8244384 @requires-related clean up in gc/metaspace/ tests
P4 JDK-8246689 [aarch64] Enable independent compressed oops/class ptrs on Aarch64
P4 JDK-8244594 [BACKOUT] 8244523: Shenandoah: Remove null-handling in LRB expansion
P4 JDK-8240722 [BACKOUT] G1DirtyCardQueue destructor has useless flush
P4 JDK-8244595 [REDO] 8244523: Shenandoah: Remove null-handling in LRB expansion
P4 JDK-8245083 [REDO] Shenandoah: Remove null-handling in LRB expansion
P4 JDK-8216557 Aarch64: Add support for Concurrent Class Unloading
P4 JDK-8242029 AArch64: skip G1 array copy pre-barrier if marking not active
P4 JDK-8244817 Add configuration logging similar to ZGCs to other GCs
P4 JDK-8246405 Add GCLogPrecious functionality to log and report debug errors
P4 JDK-8240590 Add MemRegion::destroy_array to complement introduced create_array
P4 JDK-8241976 Add test for GCPhaseConcurrentLevel1 JFR event
P4 JDK-8244815 Always log MMU information in G1
P4 JDK-8245088 Always provide logs for G1 heap expansion calculations
P4 JDK-8240246 Avoid cast_to_oop from char*
P4 JDK-8228692 BitMap::reallocate might not clear some bits
P4 JDK-8249037 clean up FileInstaller $test.src $cwd in vmTestbase_vm_g1classunloading tests
P4 JDK-8249038 clean up FileInstaller $test.src $cwd in vmTestbase_vm_gc tests
P4 JDK-8243325 Cleanup TaskQueueSuper<>::peek
P4 JDK-8243326 Cleanup use of volatile in taskqueue code
P4 JDK-8241160 Concurrent class unloading reports GCTraceTime events as JFR pause sub-phase events
P4 JDK-8237261 Concurrent refinement activation threshold not updated for card counts
P4 JDK-8243628 Deprecate -XX:ForceNUMA option
P4 JDK-8242901 Duplicate PSYoung/OldGen max size functions
P4 JDK-8238272 Eliminate cast_from_oop to narrowOop*
P4 JDK-8237143 Eliminate DirtyCardQ_cbl_mon
P4 JDK-8246258 Enable hs_err heap printing earlier during initialization
P4 JDK-8242370 Enable JFR TestGCPhaseConcurrent test for Shenandoah
P4 JDK-8244752 Enable Linux support for multiple huge page sizes -XX:LargePageSizeInBytes
P4 JDK-8241666 Enhance log messages in ReferenceProcessor
P4 JDK-8245718 Epsilon: improve configuration logging
P4 JDK-8243146 Further cleanups after UseAdaptiveGCBoundary removal
P4 JDK-8244684 G1 abuses StarTask to also include partial objarray scan tasks
P4 JDK-8240668 G1 list of all PerRegionTable does not have to be a double linkedlist any more
P4 JDK-8246274 G1 old gen allocation tracking is not in a separate class
P4 JDK-8233439 G1 zero_filled optimization when committing CardCountsTable does not work
P4 JDK-8242078 G1: Improve concurrent refinement logging
P4 JDK-8241920 G1: Lazily initialize OtherRegionsTable::_coarse_map
P4 JDK-8242038 G1: Lazily initialize RSHashTables
P4 JDK-8245086 G1: Rename measured pause time ratios
P4 JDK-8239825 G1: Simplify threshold test for mutator refinement
P4 JDK-8240133 G1DirtyCardQueue destructor has useless flush
P4 JDK-8240591 G1HeapSizingPolicy attempts to compute expansion_amount even when at full capacity
P4 JDK-8225216 gc/logging/TestMetaSpaceLog.java doesn't work for Shenandoah
P4 JDK-8249681 gc/stress/TestJNIBlockFullGC/TestJNIBlockFullGC.java fails w/ UnsatisfiedLinkError
P4 JDK-8240592 HeapRegionManager::rebuild_free_list logs 0s for the estimated free regions before
P4 JDK-8240440 Implement get_safepoint_workers() for parallel GC
P4 JDK-8245478 Implementation: JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector (Production)
P4 JDK-8244307 Improve assertions against taskqueue underflow
P4 JDK-8238979 Improve G1DirtyCardQueueSet handling of previously paused buffers
P4 JDK-8238867 Improve G1DirtyCardQueueSet::Queue::pop
P4 JDK-8241001 Improve logging in the ConcurrentGCBreakpoint mechanism
P4 JDK-8237217 Incorrect G1StringDedupEntry type used in StringDedupTable destructor
P4 JDK-8238705 jdk/jfr/event/gc/stacktrace/TestMetaspace* are unstable on arm64 with Xcomp
P4 JDK-8241457 JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector (Production)
P4 JDK-8241825 Make compressed oops and compressed class pointers independent (x86_64, PPC, S390)
P4 JDK-8249787 Make TestGCLocker more resilient with concurrent GCs
P4 JDK-8246272 Make use of GCLogPrecious for G1, Parallel and Serial
P4 JDK-8246075 Missing logging in nmethod::oops_do_marking_epilogue() on early return path
P4 JDK-8220503 Move definition of ShenandoahTerminatorTerminator::should_exit_termination() to .cpp file
P4 JDK-8245724 Move g1 periodic gc logging to G1InitLogger
P4 JDK-8238855 Move G1ConcurrentMark flag sanity checks to g1Arguments
P4 JDK-8235996 Move obsolete flag G1RSetScanBlockSize in flags list
P4 JDK-8209162 Page size selection does not always select optimal page size
P4 JDK-8245022 ParallelGC abuses StarTask to also include partial objarray scan tasks
P4 JDK-8246718 ParallelGC should not check for forward objects for copy task queue
P4 JDK-8247201 Print potential pointer value of readable stack memory in hs_err file
P4 JDK-8241153 Refactor HeapRegionManager::find_unavailable_from_idx to simplify expand_at
P4 JDK-8246622 Remove CollectedHeap::print_gc_threads_on()
P4 JDK-8241771 Remove dead code in SparsePRT
P4 JDK-8237637 Remove dubious type conversions from oop
P4 JDK-8231668 Remove ForceDynamicNumberOfGCThreads
P4 JDK-8242597 Remove GenericTaskQueue<>::push_slow
P4 JDK-8238999 Remove MemRegion custom new/delete operator overloads
P4 JDK-8245236 Remove MO_VOLATILE Access decorator
P4 JDK-8237645 Remove OopsInGenClosure::par_do_barrier
P4 JDK-8232689 Remove ParCompactionManager::Action enum
P4 JDK-8245723 Remove PrintCompressedOopsMode and change gc+heap+coops info log to debug level
P4 JDK-8238854 Remove superfluous C heap allocation failure checks
P4 JDK-8231670 Remove TaskExecutor abstraction used in preserved marks processing
P4 JDK-8238229 Remove TRACESPINNING debug code
P4 JDK-8238220 Rename OWSTTaskTerminator to TaskTerminator
P4 JDK-8240239 Replace ConcurrentGCPhaseManager
P4 JDK-8241141 Restructure humongous object allocation in G1
P4 JDK-8246135 Save important GC log lines and print them when dumping hs_err files
P4 JDK-8226797 serviceability/tmtools/jstat/GcCapacityTest.java fails with Exception: java.lang.RuntimeException: OGCMN > OGCMX (min generation capacity > max generation capacity)
P4 JDK-8242273 Shenandoah: accept either SATB or IU barriers, but not both
P4 JDK-8239904 Shenandoah: accumulated penalties should not be over 100% of capacity
P4 JDK-8242041 Shenandoah: adaptive heuristics should account evac reserve in free target
P4 JDK-8246612 Shenandoah: add timing tracking to ShenandoahStringDedupRoots
P4 JDK-8241845 Shenandoah: align ShenandoahHeapRegions to cache lines
P4 JDK-8245464 Shenandoah: allocate collection set bitmap at lower addresses
P4 JDK-8242602 Shenandoah: allow earlier recycle of trashed regions during concurrent root processing
P4 JDK-8245757 Shenandoah: AlwaysPreTouch should not disable heap resizing or uncommits
P4 JDK-8238574 Shenandoah: Assertion failure due to missing null check
P4 JDK-8241435 Shenandoah: avoid disabling pacing with "aggressive"
P4 JDK-8243478 Shenandoah: avoid implicit worker_id = 0
P4 JDK-8240917 Shenandoah: Avoid scanning thread code roots twice in all root scanner
P4 JDK-8240872 Shenandoah: Avoid updating new regions from start of evacuation
P4 JDK-8244739 Shenandoah: break superclass dependency on ShenandoahNormalMode
P4 JDK-8244200 Shenandoah: build breakages after JDK-8241743
P4 JDK-8244180 Shenandoah: carry Phase to ShWorkerTimingsTracker explicitly
P4 JDK-8245880 Shenandoah: check class unloading flag early in concurrent code root scan
P4 JDK-8248799 Shenandoah: Claim threads token in constructor of ShenandoahRootVerifier
P4 JDK-8234399 Shenandoah: Cleanup native load barrier
P4 JDK-8240948 Shenandoah: cleanup not-forwarded-objects paths after JDK-8240868
P4 JDK-8245827 Shenandoah: Cleanup Shenandoah code root iterators and root scanner
P4 JDK-8244243 Shenandoah: Cleanup Shenandoah phase timing tracking and JFR event supporting
P4 JDK-8243578 Shenandoah: Cleanup ShenandoahStringDedup::parallel_oops_do()
P4 JDK-8237570 Shenandoah: cleanup uses of allocation/free threshold in static heuristics
P4 JDK-8242641 Shenandoah: clear live data and update TAMS optimistically
P4 JDK-8242101 Shenandoah: coalesce and parallelise heap region walks during the pauses
P4 JDK-8245812 Shenandoah: compute root phase parallelism
P4 JDK-8239081 Shenandoah: Consolidate C1 LRB and native barriers
P4 JDK-8243395 Shenandoah: demote guarantee in ShenandoahPhaseTimings::record_workers_end
P4 JDK-8241139 Shenandoah: distribute mark-compact work exactly to minimize fragmentation
P4 JDK-8239868 Shenandoah: ditch C2 node limit adjustments
P4 JDK-8240534 Shenandoah: ditch debug safepoint timeout adjustment
P4 JDK-8244807 Shenandoah: ditch filter in ShenandoahUnload::unload
P4 JDK-8241841 Shenandoah: ditch one of allocation type counters in ShenandoahHeapRegion
P4 JDK-8243301 Shenandoah: ditch ShenandoahAllowMixedAllocs
P4 JDK-8245754 Shenandoah: ditch ShenandoahAlwaysPreTouch
P4 JDK-8243463 Shenandoah: ditch total_pause counters
P4 JDK-8243465 Shenandoah: ditch unused pause_other, conc_other counters
P4 JDK-8241093 Shenandoah: editorial changes in flag descriptions
P4 JDK-8242217 Shenandoah: Enable GC mode to be diagnostic/experimental and have a name
P4 JDK-8241984 Shenandoah: enhance GCTimer and JFR support
P4 JDK-8244420 Shenandoah: Ensure _disarmed_value offset < 128
P4 JDK-8243238 Shenandoah: explicit GC request should wait for a complete GC cycle
P4 JDK-8241700 Shenandoah: Fold ShenandoahKeepAliveBarrier flag into ShenandoahSATBBarrier
P4 JDK-8241351 Shenandoah: fragmentation metrics overhaul
P4 JDK-8244730 Shenandoah: gc/shenandoah/options/TestHeuristicsUnlock.java should only verify the heuristics
P4 JDK-8244953 Shenandoah: gc/shenandoah/TestStringInternCleanup fails with broken string table root
P4 JDK-8244326 Shenandoah: global statistics should not accept bogus samples
P4 JDK-8237223 Shenandoah: important flags should not be ergonomic for concurrent class unloading
P4 JDK-8245720 Shenandoah: improve configuration logging
P4 JDK-8241067 Shenandoah: improve ShenandoahNMethod::has_cset_oops arguments
P4 JDK-8241068 Shenandoah: improve ShenandoahTraversalGC constructor arguments
P4 JDK-8242212 Shenandoah: initialize ShenandoahHeuristics::_region_data eagerly
P4 JDK-8242301 Shenandoah: Inline LRB runtime call
P4 JDK-8241748 Shenandoah: inline MarkingContext TAMS methods
P4 JDK-8242229 Shenandoah: inline ShenandoahHeapRegion liveness-related methods
P4 JDK-8241842 Shenandoah: inline ShenandoahHeapRegion::region_number
P4 JDK-8245823 Shenandoah: inline/optimize ShenandoahEvacOOMScope
P4 JDK-8244510 Shenandoah: invert SHC2Support::is_in_cset condition
P4 JDK-8245726 Shenandoah: lift/cleanup ShenandoahHeuristics names and properties
P4 JDK-8246097 Shenandoah: limit parallelism in CLDG root handling
P4 JDK-8243487 Shenandoah: make _num_phases illegal phase type
P4 JDK-8241668 Shenandoah: make ShenandoahHeapRegion not derive from ContiguousSpace
P4 JDK-8242353 Shenandoah: micro-optimize region liveness handling
P4 JDK-8239354 Shenandoah: minor enhancements to traversal GC
P4 JDK-8245755 Shenandoah: missing logging for CWR Roots
P4 JDK-8237543 Shenandoah: More asserts around code roots
P4 JDK-8236851 Shenandoah: More details in Traversal GC event messages
P4 JDK-8244732 Shenandoah: move heuristics code to gc/shenandoah/heuristics
P4 JDK-8244737 Shenandoah: move mode code to gc/shenandoah/mode
P4 JDK-8244328 Shenandoah: move ShenandoahThreadLocalData::_disarmed_value initialization
P4 JDK-8236880 Shenandoah: Move string dedup cleanup into concurrent phase
P4 JDK-8246591 Shenandoah: move string dedup roots scanning to concurrent phase
P4 JDK-8242054 Shenandoah: New incremental-update mode
P4 JDK-8243291 Shenandoah: no need to retire TLABs at Init Update Refs
P4 JDK-8241838 Shenandoah: no need to trash cset during final mark
P4 JDK-8241926 Shenandoah: only print heap changes for operations that directly affect it
P4 JDK-8245124 Shenandoah: optimize code root evacuation/update during concurrent class unloading
P4 JDK-8240076 Shenandoah: pacer should cover reset and preclean phases
P4 JDK-8240511 Shenandoah: parallel safepoint workers count should be ParallelGCThreads
P4 JDK-8244226 Shenandoah: per-cycle statistics contain worker data from previous cycles
P4 JDK-8242089 Shenandoah: per-worker stats should be summed up, not averaged
P4 JDK-8242040 Shenandoah: print allocation failure type
P4 JDK-8239786 Shenandoah: print per-cycle statistics
P4 JDK-8243495 Shenandoah: print root statistics for concurrent weak/strong root phases
P4 JDK-8243464 Shenandoah: print statistic counters in time order
P4 JDK-8244759 Shenandoah: print verbose class unloading counters
P4 JDK-8228818 Shenandoah: Processing weak roots in concurrent phase when possible
P4 JDK-8237586 Shenandoah: provide option to disable periodic GC
P4 JDK-8243460 Shenandoah: purge init_update_refs_prepare counter
P4 JDK-8241545 Shenandoah: purge root work overwrites counters after JDK-8228818
P4 JDK-8242082 Shenandoah: Purge Traversal mode
P4 JDK-8245814 Shenandoah: reconsider format specifiers for stats
P4 JDK-8241743 Shenandoah: refactor and inline ShenandoahHeap::heap()
P4 JDK-8241673 Shenandoah: refactor anti-false-sharing padding
P4 JDK-8244509 Shenandoah: refactor ShenandoahBarrierC2Support::test_* methods
P4 JDK-8240671 Shenandoah: refactor ShenandoahPhaseTimings
P4 JDK-8240749 Shenandoah: refactor ShenandoahUtils
P4 JDK-8245461 Shenandoah: refine mode name()-s
P4 JDK-8245463 Shenandoah: refine ShenandoahPhaseTimings constructor arguments
P4 JDK-8241534 Shenandoah: region status should include update watermark
P4 JDK-8242267 Shenandoah: regions space needs to be aligned by os::vm_allocation_granularity()
P4 JDK-8240868 Shenandoah: remove CM-with-UR piggybacking cycles
P4 JDK-8245825 Shenandoah: Remove diagnostic flag ShenandoahConcurrentScanCodeRoots
P4 JDK-8240750 Shenandoah: remove leftover files and mentions of ShenandoahAllocTracker
P4 JDK-8245955 Shenandoah: Remove LRB/is_redundant optimization
P4 JDK-8244523 Shenandoah: Remove null-handling in LRB expansion
P4 JDK-8237017 Shenandoah: Remove racy assertion
P4 JDK-8244729 Shenandoah: remove resolve paths from SBSA::generate_shenandoah_lrb
P4 JDK-8243307 Shenandoah: remove ShCollectionSet::live_data
P4 JDK-8240215 Shenandoah: remove ShenandoahAllocationTrace
P4 JDK-8240217 Shenandoah: remove ShenandoahEvacAssist
P4 JDK-8241740 Shenandoah: remove ShenandoahHeapRegion::_heap
P4 JDK-8241692 Shenandoah: remove ShenandoahHeapRegion::_reserved
P4 JDK-8242114 Shenandoah: remove ShenandoahHeapRegion::reset_alloc_metadata_to_shared
P4 JDK-8242375 Shenandoah: Remove ShenandoahHeuristic::record_gc_start/end methods
P4 JDK-8242213 Shenandoah: remove ShenandoahHeuristics::_bytes_in_cset
P4 JDK-8242211 Shenandoah: remove ShenandoahHeuristics::RegionData::_seqnum_last_alloc
P4 JDK-8238162 Shenandoah: Remove ShenandoahTaskTerminator wrapper
P4 JDK-8240216 Shenandoah: remove ShenandoahTerminationTrace
P4 JDK-8240915 Shenandoah: Remove unused fields in init mark tasks
P4 JDK-8242228 Shenandoah: remove unused ShenandoahCollectionSet methods
P4 JDK-8246342 Shenandoah: remove unused ShenandoahIsMarkedNextClosure
P4 JDK-8243573 Shenandoah: rename GCParPhases and related code
P4 JDK-8241844 Shenandoah: rename ShenandoahHeapRegion::region_number
P4 JDK-8242075 Shenandoah: rename ShenandoahHeapRegionSize flag
P4 JDK-8244740 Shenandoah: rename ShenandoahNormalMode to ShenandoahSATBMode
P4 JDK-8240315 Shenandoah: Rename ShLBN::get_barrier_strength()
P4 JDK-8230853 Shenandoah: replace leftover assert(is_in(...)) with rich asserts
P4 JDK-8242625 Shenandoah: restore heap logging for Degenerated/Full cycles
P4 JDK-8242638 Shenandoah: restore heap logging for uncommit
P4 JDK-8242400 Shenandoah: Restore logging to pre-jdk8241984 format
P4 JDK-8241062 Shenandoah: rich asserts trigger "empty statement" inspection
P4 JDK-8244667 Shenandoah: SBC2Support::test_gc_state takes loop for wrong control
P4 JDK-8243494 Shenandoah: set counters once per cycle
P4 JDK-8240873 Shenandoah: Short-cut arraycopy barriers
P4 JDK-8241142 Shenandoah: should not use parallel reference processing with single GC thread
P4 JDK-8242130 Shenandoah: Simplify arraycopy-barrier dispatching
P4 JDK-8241985 Shenandoah: simplify collectable garbage logging
P4 JDK-8241983 Shenandoah: simplify FreeSet logging
P4 JDK-8241520 Shenandoah: simplify region sequence numbers handling
P4 JDK-8242083 Shenandoah: split "Prepare Evacuation" tracking into cset/freeset counters
P4 JDK-8242643 Shenandoah: split concurrent weak and strong root processing
P4 JDK-8245465 Shenandoah: test_in_cset can use more efficient encoding
P4 JDK-8246458 Shenandoah: TestAllocObjects.java test fail with -XX:+ShenandoahVerify
P4 JDK-8243008 Shenandoah: TestVolatilesShenandoah test failed on aarch64
P4 JDK-8242227 Shenandoah: transit regions to cset state when adding to collection set
P4 JDK-8242042 Shenandoah: tune down ShenandoahGarbageThreshold
P4 JDK-8241583 Shenandoah: turn heap lock asserts into macros
P4 JDK-8240069 Shenandoah: turn more flags diagnostic
P4 JDK-8242316 Shenandoah: Turn NULL-check into assert in SATB slow-path entry
P4 JDK-8242365 Shenandoah: use uint16_t instead of jushort for liveness cache
P4 JDK-8246100 Shenandoah: walk roots in more efficient order
P4 JDK-8246433 Shenandoah: walk roots in more efficient order in ShenandoahRootUpdater
P4 JDK-8243848 Shenandoah: Windows build fails after JDK-8239786
P4 JDK-8241830 Simplify commit error messages in G1PageBasedVirtualSpace
P4 JDK-8244010 Simplify usages of ProcessTools.createJavaProcessBuilder in our tests
P4 JDK-8243565 some gc tests use 'test.java.opts' and not 'test.vm.opts'
P4 JDK-8233220 Space::_par_seq_tasks is unused after CMS removal
P4 JDK-8230349 Test jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithParallel.java fails with GC overhead limit exceeded on several MacOS servers
P4 JDK-8242031 TestLookForUntestedEvents.java fails because newly added test tests experimental events
P4 JDK-8246434 Threads::print_on_error assumes that the heap has been set up
P4 JDK-8232686 Turn parallel gc develop tracing flags into unified logging
P4 JDK-8238160 Uniformize Parallel GC task queue variable names
P4 JDK-8183574 Unify the is_power_of_2 functions
P4 JDK-8237182 Update copyright header for shenandoah and epsilon files
P4 JDK-8236878 Use atomic instruction to update StringDedupTable's entries and entries_removed counters
P4 JDK-8243933 Use driver mode in gc tests
P4 JDK-8245087 Use ratios instead of percentages in G1HeapSizingPolicy::expansion_amount
P4 JDK-8243434 use reproducible random in :vmTestbase_vm_g1classunloading
P4 JDK-8243430 use reproducible random in :vmTestbase_vm_gc
P4 JDK-8242312 use reproducible random in hotspot gc tests
P4 JDK-8243942 Use SkippedException in gc/arguments/TestSmallInitialHeapWithLargePageAndNUMA.java test
P4 JDK-8216975 Using ForceNUMA does not disable adaptive sizing with parallel gc
P4 JDK-8241881 ZGC: Add tests for JFR events
P4 JDK-8243486 ZGC: Adjust "Allocated" statistics to take undone page allocations into account
P4 JDK-8239129 ZGC: Allow -XX:AllocateHeapAt to use any filesystem
P4 JDK-8245208 ZGC: Don't hold the ZPageAllocator lock while committing/uncommitting memory
P4 JDK-8245203 ZGC: Don't track size in ZPhysicalMemoryBacking
P4 JDK-8236153 ZGC: gc/z/TestUncommit.java fails with java.lang.Exception: Uncommitted too fast
P4 JDK-8246406 ZGC: Generate crash reports in debug builds for a few important errors paths
P4 JDK-8241361 ZGC: Implement memory related JFR events
P4 JDK-8237649 ZGC: Improved NUMA support when using small pages
P4 JDK-8246265 ZGC: Introduce ZConditionLock
P4 JDK-8245204 ZGC: Introduce ZListRemoveIterator
P4 JDK-8246220 ZGC: Introduce ZUnmapper to asynchronous unmap pages
P4 JDK-8245233 ZGC: Load volatile oops using Atomic::load()
P4 JDK-8239533 ZGC: Make the ZProactive flag non-diagnostic
P4 JDK-8237758 ZGC: Move get_mempolicy() syscall wrapper to ZSyscall
P4 JDK-8245196 ZGC: No need to disable UseBiasedLocking by default
P4 JDK-8234440 ZGC: Print relocation information on info level
P4 JDK-8245450 ZGC: Remove unused ZArguments::initialize_platform()
P4 JDK-8237201 ZGC: Remove unused ZRelocationSetSelector::fragmentation()
P4 JDK-8237882 ZGC: Remove ZUtils::round_{up,down}_power_of_2() declarations
P4 JDK-8237199 ZGC: Rename ZBackingFile to ZPhysicalMemoryBacking
P4 JDK-8237200 ZGC: Rename ZBackingPath to ZMountPoint
P4 JDK-8246044 ZGC: Rename ZDirector's max_capacity to soft_max_capacity
P4 JDK-8237825 ZGC: Replace -XX:ZPath with -XX:AllocateHeapAt
P4 JDK-8246134 ZGC: Restructure hs_err sections
P4 JDK-8235905 ZGC: Rework how ZRootsIterator visits threads
P4 JDK-8237198 ZGC: Share multi-mapping code in ZBackingFile
P4 JDK-8242527 ZGC: TestUncommit.java fails due to "Exception: Uncommitted too fast"
P4 JDK-8237884 ZGC: Use clamp() instead of MIN2(MAX2())
P4 JDK-8246404 ZGC: Use GCLogPrecious for important logging lines
P4 JDK-8247214 ZGC: ZUncommit initialization should use precious logging
P5 JDK-8244714 G1 young gen sizer allows zero young gen with huge -XX:NewRatio
P5 JDK-8246557 test_os_linux.cpp uses NULL instead of MAP_FAILED to check for failed mmap call
P5 JDK-8233822 VM_G1CollectForAllocation should always check for upgrade to full
P5 JDK-8240714 ZGC: TestSmallHeap.java failed due to OutOfMemoryError

hotspot/jfr

Priority Bug Summary
P2 JDK-8246770 Atomic::add() with 64 bit value fails to link on 32-bit platforms
P2 JDK-8237887 CDSandJFR: assert(instance_klass->is_initialized())
P2 JDK-8239376 JFR: assert(!cld->is_unsafe_anonymous()) failed: invariant
P2 JDK-8245283 JFR: Can't handle constant dynamic used by Jacoco agent
P2 JDK-8238592 JFR: Crash when dumping paths to gc roots on deep heaps
P2 JDK-8249713 JFR: java.base events have incomplete stacktraces
P2 JDK-8245120 JFR: Parser unable to return typed version
P2 JDK-8247530 JfrCheckpointManager failed "assert(!SafepointSynchronize::is_at_safepoint()) failed: invariant"
P2 JDK-8247967 SparkExamples24H.java SIGSEGV in various places
P3 JDK-8239793 'jfr' tool should hide hidden frames
P3 JDK-8244920 Access violation in frames::interpreter_frame_method
P3 JDK-8237364 Add early validation to the jdk.jfr.Recording constructor
P3 JDK-8238236 Add JFR class redefinition events
P3 JDK-8238959 Add missing classpath exception to FileAcess and ConstantLookup
P3 JDK-8239350 Add tests for JFR class redefinition events
P3 JDK-8241718 assert ((klass)->trace_id()) & ((JfrTraceIdEpoch::method_and_class_in_use_this_epoch_bits()))) != 0 in ObjectSampleCheckpoint::add_to_leakp_set
P3 JDK-8219904 ClassCastException when calling FlightRecorderMXBean#getRecordings()
P3 JDK-8238083 Crash: assert(is_object_aligned(v)) failed: address not aligned: 0xfffffffffffffff1
P3 JDK-8239584 EventStream::close should state that stream will be stopped
P3 JDK-8239581 Improve javadoc example for @jdk.jfr.Category
P3 JDK-8242933 jdk/jfr/api/consumer/TestHiddenMethod uses nashorn script engine
P3 JDK-8237488 jdk/jfr/event/compiler/TestCompilerCompile.java failed due to "RuntimeException: No thread in event"
P3 JDK-8222001 JFR event for heap dumps written
P3 JDK-8245113 JFR Recorder Thread to run in thread state "_thread_in_native"
P3 JDK-8241695 JFR TestCrossProcessStreaming.java child process exited with SIGQUIT (131)
P3 JDK-8232636 JFR TestDumpOnCrash.java crashed and failed to create emergency dump file
P3 JDK-8247247 JFR tests fail due to JDK-8235521 missing doPrivileged block
P3 JDK-8241803 JFR TestThreadStartEndEvents.java failed due to "RuntimeException: Wrong thread id"
P3 JDK-8244463 JFR: Clean up jdk.jfr.internal.RepositoryChunk
P3 JDK-8243452 JFR: Could not create chunk in repository with over 200 recordings
P3 JDK-8240778 JFR: Create timer task lazily
P3 JDK-8246259 JFR: Fetch VM memory pools without using streams
P3 JDK-8244508 JFR: FlightRecorderOptions reset date format
P3 JDK-8237499 JFR: Include stack trace in the ThreadStart event
P3 JDK-8239585 JFR: Native events should support empty payloads
P3 JDK-8222000 JFR: Process start event
P3 JDK-8247269 JFR: Reduce allocation when using AnnotationElement
P3 JDK-8247320 JFR: Reduce logging overhead
P3 JDK-8244661 JFR: Remove use of thread-locals for java.base events
P3 JDK-8216303 JFR: Simplify generated files
P3 JDK-8227559 JFR: Slow dump with path-to-gc-roots=true
P3 JDK-8240783 JFR: TestClose could not finish chunk
P3 JDK-8246260 JFR: Write event size field without padding
P3 JDK-8242240 JfrStacktrace_lock rank not special enough
P3 JDK-8239024 Kitchensink24HStress.java failed due to timeout
P3 JDK-8233705 Let artifact iteration running time be a function of incrementally tagged artifacts
P3 JDK-8237014 Missing javadoc for jdk.jfr.Recording(Map)
P3 JDK-8248485 Poor scalability in JfrCheckpointManager when using many threads after JDK-8242088
P3 JDK-8238634 Reduce log verbosity of the JFR thread sampler
P3 JDK-8227610 Remove allocation when getting EventHandler
P3 JDK-8242088 Replace mutually exclusive lists with concurrent alternatives
P3 JDK-8238180 RunThese30M failed "assert(t->jfr_thread_local()->shelved_buffer() == __null) failed: invariant"
P3 JDK-8239497 SEGV in EdgeUtils::field_name_symbol(Edge const&)
P3 JDK-8248475 Suppress unconditional warning "JFR will be disabled during CDS dumping"
P3 JDK-8242934 test/jdk/jdk/jfr/tool/TestPrintJSON.java uses nashorn script engine
P3 JDK-8238224 test\jdk\jdk\jfr\event\io\EvilInstrument.java should be removed
P3 JDK-8219999 TestJFREvents container test should not use jdk.CPUInformation event for container CPU values
P3 JDK-8248794 Transition JFR Periodic Task Thread to "_thread_in_native" before invoking performance counters
P4 JDK-8223066 "jfr metadata" output the @Name annotation twice
P4 JDK-8238665 Add JFR event for direct memory statistics
P4 JDK-8240819 Assign a name to the JfrThreadSampler thread
P4 JDK-8244777 ClassLoaderStats VM Op uses constant hash value
P4 JDK-8243563 Doc comments cleanup
P4 JDK-8242188 error in jtreg test jdk/jfr/api/consumer/TestRecordedFrame.java on linux-aarch64
P4 JDK-8240634 event/runtime/TestMetaspaceAllocationFailure.java times out
P4 JDK-8242792 interval < flushInterval is always false in jdk.jfr.internal.RequestEngine#setFlushInterval
P4 JDK-8244149 jdk/jfr/api/consumer/recordingstream/TestOnEvent.java times out
P4 JDK-8235921 jdk/jfr/event/oldobject/TestLargeRootSet.java times out with debug bits
P4 JDK-8210977 jdk/jfr/event/oldobject/TestThreadLocalLeak.java fails to find ThreadLocalObject
P4 JDK-8219686 jdk/jfr/event/runtime/TestShutdownEvent.java recording file length is 0
P4 JDK-8239423 jdk/jfr/jvm/TestJFRIntrinsic.java failed with -XX:-TieredCompilation
P4 JDK-8233706 JFR emergency dump should be performed after error reporting
P4 JDK-8241064 JFR related tests TestMetaspaceAllocationFailure.java and TestEventInstrumentation.java miss requires tag
P4 JDK-8241263 JFR: Bump native events limit
P4 JDK-8242844 JFR: Clean up typos and log format
P4 JDK-8246128 JFR: Fix warnings
P4 JDK-8240773 JFR: Non-Java threads are not serialized
P4 JDK-8246130 JFR: TestInheritedAnnotations has incorrect validation
P4 JDK-8215452 Logged repo location is wrong when using delayed recording start
P4 JDK-8240360 NativeLibraryEvent has wrong library name on Linux
P4 JDK-8240738 nested comment in JVM.java and other minor formatting errors
P4 JDK-8240818 Remove colon from "JFR: Shutdown Hook" thread name
P4 JDK-8242034 Remove JRE_HOME references
P4 JDK-8244775 Remove unnecessary dependency to jfrEvents.hpp
P4 JDK-8244676 test/jdk/jdk/jfr/startupargs/TestOptionsWithLocale.java fails
P4 JDK-8243489 Thread CPU Load event may contain wrong data for CPU time under certain conditions

hotspot/jvmti

Priority Bug Summary
P2 JDK-8230502 Add support in JVM TI, JDI, and Instrumentation for hidden classes
P2 JDK-8247248 JVM TI Monitor queries might create JNI locals in another thread when using handshakes.
P3 JDK-8222005 ClassRedefinition crashes with: guarantee(false) failed: OLD and/or OBSOLETE method(s) found
P3 JDK-8242237 Improve JVM TI HiddenClasses tests
P3 JDK-8245126 Kitchensink fails with: assert(!method->is_old()) failed: Should not be installing old methods
P3 JDK-8246442 nmethod::can_convert_to_zombie() asserts when not called by the sweeper
P4 JDK-8243941 build issue introduced with the push of 8242237
P4 JDK-8245854 JVM TI Specification for sealed classes
P4 JDK-8242425 JVMTI monitor operations should use Thread-Local Handshakes
P4 JDK-8221306 JVMTI spec for FramePop(), MethodExit(), and MethodEnter() could use some cleanup
P4 JDK-8235912 JvmtiBreakpoint remove oops_do and metadata_do
P4 JDK-8238585 JvmtiEventControllerPrivate::enter_interp_only_mode() should not make compiled methods on stack not_entrant
P4 JDK-8245321 refactor the redefine check that an attribute consisting of a list of classes has not changed
P4 JDK-8245392 Remove duplication in class redefinition and retransformation specs
P4 JDK-8242896 typo #ifdef INCLUDE_JVMTI in codeCache.cpp
P4 JDK-8236190 Unproblem list vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t002/TestDescription.java
P4 JDK-8243435 use reproducible random in :vmTestbase_nsk_jvmti

hotspot/other

Priority Bug Summary
P2 JDK-8236856 AArch64: Spurious GCC warnings
P4 JDK-8241787 JEP 381: Remove the Solaris and SPARC Ports

hotspot/runtime

Priority Bug Summary
P1 JDK-8243997 Linux build failed after JDK-8242244
P1 JDK-8239854 Non-PCH gtest build fails after JDK-8239235 due to a missing include
P2 JDK-8231612 100% cpu on arm32 in Service Thread
P2 JDK-8245703 32-bit build failures after JDK-8243392
P2 JDK-8237753 32-bit builds are broken after JDK-8230594
P2 JDK-8237479 8230305 causes slowdebug build failure
P2 JDK-8236901 8232759 missed a test case
P2 JDK-8241124 Aarch64 build broken by JDK-8239593
P2 JDK-8237747 Build broken on macOS by JDK-8235741 - wrong format specifier
P2 JDK-8241723 Build error after 8241581
P2 JDK-8239514 Build for arm-linux-gnueabihf fails with undefined reference 'read_polling_page'
P2 JDK-8242913 Bump the SPECIAL_FLAG_VALIDATION_BUILD to 25
P2 JDK-8247388 Minimal build broken after JDK-8240245 (undefined reference to `MetaspaceShared::_use_optimized_module_handling')
P2 JDK-8243572 Multiple tests fail with assert(cld->klasses() != 0LL) failed: unexpected NULL for cld->klasses()
P2 JDK-8239363 PPC64: Wrong code generation after JDK-8183574
P2 JDK-8235966 Process obsolete flags less aggressively
P2 JDK-8238600 Remove runtime/fieldType.hpp and fieldType.cpp
P2 JDK-8241296 Segfault in JNIHandleBlock::oops_do()
P2 JDK-8245264 Test runtime/cds/appcds/SignedJar.java fails
P2 JDK-8235965 Tests using ThreadLocalHandshakes need to stop using it as it no longer exists
P2 JDK-8241128 x86_32 build failure after JDK-8241042
P2 JDK-8247377 Zero and Minimal VMs are broken after JDK-8198698 ('SystemDictionaryShared' has not been declared)
P2 JDK-8237847 Zero builds fail after JDK-8237637 (Remove dubious type conversions from oop)
P3 JDK-8237756 [BACKOUT]: JDK-8230594: Allow direct handshakes without VMThread intervention
P3 JDK-8244949 [PPC64] Reengineer assembler stop function
P3 JDK-8240918 [REDO] Allow direct handshakes without VMThread intervention
P3 JDK-8240588 _threadObj cannot be used on an exiting JavaThread.
P3 JDK-8248219 aarch64: missing memory barrier in fast_storefield and fast_accessfield
P3 JDK-8239787 AArch64: String.indexOf may incorrectly handle empty strings.
P3 JDK-8243045 AOTCompiledMethod::print_on triggers assertion after JDK-8210012
P3 JDK-8238643 ARM32 build fails after JDK-8230199
P3 JDK-8236242 Arm32: build broken after 8234794
P3 JDK-8248112 array index out of bound in FileMapInfo::check_paths
P3 JDK-8239895 assert(_stack_base != 0LL) failed: Sanity check
P3 JDK-8236177 assert(status == 0) failed: error ETIMEDOUT(60), cond_wait
P3 JDK-8238961 Assertion failure in new field layout code when ContendedPaddingWidth == 0.
P3 JDK-8178349 Cache builtin class loader constraints to avoid re-initializing itable/vtable for shared classes
P3 JDK-8240197 Cannot start JVM when $JAVA_HOME includes CJK characters
P3 JDK-8241244 CDS dynamic dump asserts in ArchivePtrBitmapCleaner::do_bit
P3 JDK-8239785 Cgroups: Incorrect detection logic on old systems in hotspot
P3 JDK-8239559 Cgroups: Incorrect detection logic on some systems
P3 JDK-8240529 CheckUnhandledOops breaks NULL check in Modules::define_module
P3 JDK-8186780 clang fastdebug assertion failure in os_linux_x86:os::verify_stack_alignment()
P3 JDK-8246359 clarify confusing comment in ObjectMonitor::EnterI()'s race with async deflation
P3 JDK-8230199 consolidate signature parsing code in HotSpot sources
P3 JDK-8238000 Crash in ClassLoader::record_result while dynamic dumping netty
P3 JDK-8238175 CTW: Class.getDeclaredMethods fails with assert(k->is_subclass_of(SystemDictionary::Throwable_klass())) failed: invalid exception class
P3 JDK-8236236 Eliminate CDS md region and consolidate c++ vtable patching code
P3 JDK-8233014 Enable ShowCodeDetailsInExceptionMessages by default
P3 JDK-8240824 enhance print_full_memory_info on Linux by THP related information
P3 JDK-8239235 Examine SignatureStream performance after consolidation
P3 JDK-8241043 Expand assertions to identify thread with errant _stack_base
P3 JDK-8237080 fatal error: VM thread could block on lock that may be held by a JavaThread during safepoint: SharedDecoder_lock
P3 JDK-8237767 Field layout computation overhaul
P3 JDK-8241071 Generation of classes.jsa with -Xshare:dump is not deterministic
P3 JDK-8245042 Improve scalability of reading Windows Performance counters via PDH when using the Process object
P3 JDK-8240615 is_power_of_2() has Undefined Behaviour and is inconsistent
P3 JDK-8235256 JEP 374: Deprecate and Disable Biased Locking
P3 JDK-8238676 jni crashes on accessing it from process exit hook
P3 JDK-8237857 LogDecorations::uptimenanos is implemented incorrectly
P3 JDK-8153224 Monitor deflation prolong safepoints
P3 JDK-8246676 monitor list lock operations need more fencing
P3 JDK-8247280 more fencing needed in async deflation for non-TSO machines
P3 JDK-8246340 Move SystemDictionary GC roots into OopStorage
P3 JDK-8241004 NMT tests fail on unaligned thread size with debug build
P3 JDK-8248476 No helpful NullPointerException message after calling fillInStackTrace.
P3 JDK-8243936 NonWriteable system properties are actually writeable
P3 JDK-8230940 Obsolete MonitorBound
P3 JDK-8236224 Obsolete the FieldsAllocationStyle and CompactFields options
P3 JDK-8236604 Optimize SystemDictionary::resolve_well_known_classes for CDS
P3 JDK-8234691 Potential double-free in ParallelSPCleanupTask constructor
P3 JDK-8238460 Provide warnings about the use of JNI RegisterNatives to rebind native methods for boot/platform classes in other classloaders
P3 JDK-8231559 Remove expired flags in JDK 15
P3 JDK-8241158 SA TestHeapDumpForInvokeDynamic.java fails when CDS archive is relocated
P3 JDK-8244495 Some jlink tests crash on Windows after JDK-8237750
P3 JDK-8198698 Support Lambda proxy classes in dynamic CDS archive
P3 JDK-8237830 support O_CLOEXEC in os::open on other OS than Linux
P3 JDK-8242921 test/hotspot/jtreg/runtime/CompactStrings/TestMethodNames.java uses nashorn script engine
P3 JDK-8247252 TestCombinedCompressedFlags.java failed src/hotspot/share/services/virtualMemoryTracker.cpp:388 Error: ShouldNotReachHere()
P3 JDK-8232081 Try to link all classes during dynamic CDS dump
P3 JDK-8240267 VM fails to start with CDS enabled but JVMTI disabled
P3 JDK-8225056 VM support for sealed classes
P3 JDK-8240603 Windows 32bit compile error after 8238676
P4 JDK-8237777 "Dumping core ..." is shown despite claiming that "# No core dump will be written."
P4 JDK-8239014 -XX:-UseEmptySlotsInSupers sometime fails to reproduce the layout of the old code
P4 JDK-8241018 32-bit integer log2 functions return the wrong value for negative arguments on 64-bit machines
P4 JDK-8238284 [macos] Zero VM build fails due to an obvious typo
P4 JDK-8246377 [PPC64] Further improvements for assembler stop function
P4 JDK-8241101 [s390] jtreg test failure after JDK-8238696: not conformant features string
P4 JDK-8239492 [x86] Turn MacroAssembler::verify_oop into macro recording file and line
P4 JDK-8245137 aarch64 ICache flush depends on enabling gnu extensions
P4 JDK-8237512 AArch64: aarch64TestHook leaks a BufferBlob
P4 JDK-8242905 AArch64: Client build failed
P4 JDK-8236992 AArch64: redundant load_klass in itable stub
P4 JDK-8234794 AArch64: runtime/memory/ReadFromNoaccessArea.java crashes
P4 JDK-8236778 Add Atomic::fetch_and_add
P4 JDK-8241581 Add BitMap::count_one_bits variant for arbitrary lengths
P4 JDK-8187305 Add logging for shared library loads/unloads
P4 JDK-8235931 add OM_CACHE_LINE_SIZE and use smaller size on SPARCv9 and X64
P4 JDK-8244733 Add ResourceHashtable::xxx_if_absent
P4 JDK-8241660 Add virtualization information output to hs_err file on macOS
P4 JDK-8244196 adjust output in os_linux
P4 JDK-8230594 Allow direct handshakes without VMThread intervention
P4 JDK-8229971 Arm32: implementation for Thread-local handshakes
P4 JDK-8246382 assert in MetaspaceShared::map_archives
P4 JDK-8247522 assert(is_aligned(class_space_rs.base(), class_space_alignment)) failed: Sanity
P4 JDK-8240263 Assertion-only call in Method::link_method affecting product builds
P4 JDK-8240245 Avoid calling is_shared_class_visible() in SystemDictionary::load_shared_class()
P4 JDK-8240244 Avoid calling resolve_super_or_fail in SystemDictionary::load_shared_class
P4 JDK-8240205 Avoid PackageEntry lookup when loading shared classes
P4 JDK-8238198 Avoid using @ tags in TestOptionsWithRanges_generate.sh
P4 JDK-8235714 BitMap::count_one_bits may count bits beyond unaligned end
P4 JDK-8239593 Bogus warning "Re-registering of platform native method" for a JVMTI agent
P4 JDK-8240231 Build failure on illumos after 8238988
P4 JDK-8240695 Build is broken when cds is disabled after JDK-8232081
P4 JDK-8240254 Build is broken when cds is disabled after JDK-8236604
P4 JDK-8244536 cds/DeterministicDump.java failed: File content different
P4 JDK-8239537 cgroup MetricsTester testMemorySubsystem fails sometimes when testing memory.kmem.tcp.usage_in_bytes
P4 JDK-8230305 Cgroups v2: Container awareness
P4 JDK-8234628 Change BasicHashTables::new_entry() to use clamp()
P4 JDK-8233826 Change CDS dumping tty->print_cr() to unified logging
P4 JDK-8240530 CheckUnhandledOops breaks BacktraceBuilder::set_has_hidden_top_frame
P4 JDK-8249032 clean up FileInstaller $test.src $cwd in vmTestbase_nsk_sysdict tests
P4 JDK-8249029 clean up FileInstaller $test.src $cwd in vmTestbase_vm_defmeth tests
P4 JDK-8249033 clean up FileInstaller $test.src $cwd in vmTestbase_vm_metaspace tests
P4 JDK-8242898 Clean up InstanceKlass::_array_klasses
P4 JDK-8242027 Clean up LinkResolver::check_klass_accessability
P4 JDK-8242000 clean up list of environment variables printed in hs_err file
P4 JDK-8246926 Clean up newlines and whitespaces in hs_err files
P4 JDK-8245289 Clean up offset code in JavaClasses
P4 JDK-8245035 Clean up os::split_reserved_memory()
P4 JDK-8238782 Cleanup Deoptimization::deoptimize(): remove unused RegisterMap argument and don't update RegisterMap in callers if UseBiasedLocking is enabled
P4 JDK-8241852 Cleanup error message generation in LinkResolver::resolve_field
P4 JDK-8223699 cleanup perfMemory_aix.cpp O_NOFOLLOW coding on aix
P4 JDK-8241837 Cleanup stringStream usage in ObjectSynchronizer
P4 JDK-8241006 Cleanup TemplateInterpreter initialization
P4 JDK-8237382 Cleanup the OPT_SPEED_SRC file list in JvmFeatures.gmk
P4 JDK-8238048 Close alignment gaps in InstanceKlass
P4 JDK-8241427 Coarsen locking in Modules::add_module_exports
P4 JDK-8241009 CommandLineFlagComboNegative.java fails after JDK-8240563
P4 JDK-8241586 compiler/cpuflags/TestAESIntrinsicsOnUnsupportedConfig.java fails on aarch64
P4 JDK-8241665 Configuring --with-jvm-features=-compiler2 fails to build on AArch64
P4 JDK-8242134 Consolidate the get_package_entry() in SystemDictionaryShared and ClassLoader
P4 JDK-8245509 Crash handler itself crashes when reporting Unsafe.putInt(0) crash
P4 JDK-8245833 crash_with_sigfpe uses pthread_kill(SIGFPE) on macOS
P4 JDK-8242424 Deprecate InitialBootClassLoaderMetaspaceSize
P4 JDK-8236844 Deprecate PrintVMQWaitTime to prepare for its removal
P4 JDK-8243147 Deprecate UseLargePagesInMetaspace
P4 JDK-8242452 During module definition, move conversion of packages from native to VM
P4 JDK-8232069 Enable CDS even when UseCompressedClassPointers and/or UseCompressedOops are false
P4 JDK-8241948 enhance list of environment variables printed in hs_err file
P4 JDK-8243389 enhance os::pd_print_cpu_info on linux
P4 JDK-8242626 enhance posix print_rlimit_info
P4 JDK-8235671 enhance print_rlimit_info in os_posix
P4 JDK-8237766 Enhance signature API to include ResolvingSignatureStream
P4 JDK-8242504 Enhance the system clock to nanosecond precision
P4 JDK-8241395 Factor out platform independent code for os::xxx_memory_special()
P4 JDK-8244946 fatal error: memory leak: allocating without ResourceMark with -XX:+Verbose -Xlog:methodhandles
P4 JDK-8247236 fieldDescriptor::print_on_for prints extra newline after NULL
P4 JDK-8239000 handle ContendedPaddingWidth in vm_version_ppc
P4 JDK-8244340 Handshake processing thread lacks yielding
P4 JDK-8240532 heap inspection prints trailing @ after name of module without version
P4 JDK-8240295 hs_err elapsed time in seconds is not accurate enough
P4 JDK-8210012 Implement Unified Logging Option for -XX:+TraceMethodHandles and -XX:+TraceInvokeDynamic
P4 JDK-8231264 Implementation of JEP 374: Disable biased-locking and deprecate all flags related to biased-locking
P4 JDK-8240324 Improve is_boot_class_loader_data() by adding simple check
P4 JDK-8243393 Improve ReservedSpace constructor resolution
P4 JDK-8235741 Inappropriate uses of os::javaTimeMillis()
P4 JDK-8240982 Incorrect copyright header in BCEL 6.4.1 sources
P4 JDK-8240141 Incorrect copyright header in src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp
P4 JDK-8244107 Incorrect parameters in ReservedSpace constructor change
P4 JDK-8245707 Increase Metaspace reserve alignment
P4 JDK-8243503 InstanceKlass::_array_name is not needed and leaks
P4 JDK-8240613 InstanceKlass::set_init_state failed with "assert(good_state || state == allocated): illegal state transition"
P4 JDK-8234372 Investigate use of Thread::stack_base() and queries for "in stack"
P4 JDK-8246648 issue with OperatingSystemImpl getFreeSwapSpaceSize in docker after 8242480
P4 JDK-8236489 Java heap file on daxfs should be more secure
P4 JDK-8241439 jdk.NativeLibraryEvent hooks all opened regular files
P4 JDK-8237750 Load libzip.so only if necessary
P4 JDK-8239066 make LinkedList more generic
P4 JDK-8247220 Make OopHandle constructor explicit
P4 JDK-8244491 make runtime/cds/appcds/TestZGCWithCDS.java test more robust
P4 JDK-8245098 Make SafeFetch32/N available earlier
P4 JDK-8239070 Memory leak when unsuccessfully mapping in archive regions
P4 JDK-8237752 Minimal VM build fails after JDK-8236236
P4 JDK-8239886 Minimal VM build fails after JDK-8237499
P4 JDK-8242631 Missing but used special functions for some classes
P4 JDK-8245260 Missing file header for test/hotspot/jtreg/containers/docker/TEST.properties
P4 JDK-8233093 Move CDS heap oopmaps into new MetaspaceShared::bm region
P4 JDK-8243535 NMT may show wrong numbers for CDS and CCS
P4 JDK-8244606 Non-PCH build is broken after JDK-8244550
P4 JDK-8242485 Null _file checking in fileStream::flush()
P4 JDK-8245850 Obsolete UseLWPSynchronization
P4 JDK-8235908 omit ThreadPriorityPolicy warning when value is set from image
P4 JDK-8225760 oop::raw_set_obj isn't needed
P4 JDK-8240204 Optimize package handling for archived classes
P4 JDK-8238762 Optimized build is broken
P4 JDK-8235962 os::current_thread_id() is not signal safe on macOS
P4 JDK-8242290 Pointless verification in get_package_entry_by_name
P4 JDK-8245487 Potential double-free of interfaces array
P4 JDK-8234599 PPC64: Add support on recent CPUs and Linux for JEP-352
P4 JDK-8241726 Re-enable gtest for BitMap::count_one_bits()
P4 JDK-8166358 Re-enable String verification in java_lang_String::create_from_str()
P4 JDK-8241371 Refactor and consolidate package_from_name
P4 JDK-8236035 refactor ObjectMonitor::set_owner() and _owner field setting
P4 JDK-8239347 Refactor Symbol to make _length a standalone field again
P4 JDK-8243392 Remodel CDS/Metaspace storage reservation
P4 JDK-8242003 Remove CallInfo::_selected_klass
P4 JDK-8240481 Remove CDS usage of InstanceKlass::is_in_error_state
P4 JDK-8220051 Remove global safepoint code
P4 JDK-8243996 Remove hardcoded field offsets from HotSpot
P4 JDK-8235956 Remove javaClasses offset tests
P4 JDK-8232733 Remove need to grab Threads_lock while processing handshakes
P4 JDK-8242244 Remove redundant ELF machine definitions
P4 JDK-8245521 Remove STACK_BIAS
P4 JDK-8236766 Remove un-used oops do and drain list in VM thread.
P4 JDK-8235678 Remove unnecessary calls to Thread::current() in MutexLocker calls
P4 JDK-8246109 Remove unneeded undef CS
P4 JDK-8241585 Remove unused _recursion_counter facility from PerfTraceTime
P4 JDK-8241584 Remove unused classLoader perf counters
P4 JDK-8241419 Remove unused InterfaceSupport::_number_of_calls
P4 JDK-8245428 Remove unused oopFactory functions
P4 JDK-8245594 Remove volatile-qualified member functions and parameters from oop class
P4 JDK-8236625 Remove writeable macro from JVM flags declaration
P4 JDK-8238988 Rename thread "in stack" methods and add is_in_stack_range
P4 JDK-8246837 Rename WeakHandle to better reflect its OopStorage association
P4 JDK-8235225 Replace CHECK_0 with CHECK_NULL for non-integer returning methods
P4 JDK-8235795 replace monitor list mux{Acquire,Release}(&gListLock) with spin locks
P4 JDK-8239357 Revert gcc implementation of offset_of
P4 JDK-8242484 Rework thread deletion during VM termination
P4 JDK-8240840 Rollback whitebox.cpp in push 8240691
P4 JDK-8244485 runtime/cds/appcds/TestZGCWithCDS.java fails after 8244385
P4 JDK-8240546 runtime/cds/appcds/TestZGCWithCDS.java fails with Graal
P4 JDK-8232213 runtime/MemberName/MemberNameLeak.java fails intermittently
P4 JDK-8237819 s390x - remove unused pd_zero_to_words_large
P4 JDK-8235766 SafepointSynchronize::_end_of_last_safepoint is unused
P4 JDK-8243568 serviceability/logging/TestLogRotation.java uses 'test.java.opts' and not 'test.vm.opts'
P4 JDK-8243506 SharedBaseAddress is ignored by -Xshare:dump
P4 JDK-8241934 Simplify parse_stream() and remove has_class_mirror_holder_cld()
P4 JDK-8244142 some hotspot/runtime tests don't check exit code of forked JVM
P4 JDK-8240258 SystemDictionary::quick_resolve need guarded by INCLUDE_CDS
P4 JDK-8235913 ThreadStop should be a handshake
P4 JDK-8241705 Tune PerfData collections
P4 JDK-8244173 Uncomment subtest in runtime/InvocationTests/invocationC1Tests.java
P4 JDK-8241010 Unnecessarily resolving some well-known classes
P4 JDK-8241815 Unnecessary calls to SystemDictionaryShared::define_shared_package
P4 JDK-8244550 Unsafe::allocateInstance does redundant transitions
P4 JDK-8234206 Update the java command manpage in relation to biased-locking options
P4 JDK-8244141 use @requires and SkippedException in some hotspot/runtime tests
P4 JDK-8238289 Use _byteswap_ functions to implement Bytes::swap_uX on Windows
P4 JDK-8242524 Use different default CDS archives depending on UseCompressOops
P4 JDK-8243945 use driver mode in runtime tests
P4 JDK-8239461 Use jcod rather than jar files in runtime tests
P4 JDK-8243433 use reproducible random in :vmTestbase_nsk_sysdict
P4 JDK-8243432 use reproducible random in :vmTestbase_vm_defmeth
P4 JDK-8243431 use reproducible random in :vmTestbase_vm_metaspace
P4 JDK-8242311 use reproducible random in hotspot runtime tests
P4 JDK-8243944 use SkippedException and @requires in runtime/memory/ReadFromNoaccessArea.java test
P4 JDK-8244385 various clean-ups in runtime tests
P4 JDK-8245717 VM option "-XX:EnableJVMCIProduct" could not be repetitively enabled
P4 JDK-8240302 x64: Assembler::reachable redundantly call Relocation::type() more than once
P4 JDK-8241095 x86: Improve prefix handling in Assembler
P4 JDK-8241042 x86_64: Improve Assembler generation
P4 JDK-8241077 x86_64: Minor Assembler improvements
P4 JDK-8240772 x86_64: Pre-generate Assembler::popa, pusha and vzeroupper
P4 JDK-8244276 Zero and minimal VM build failure after JDK-8178349 (use of undeclared identifier 'SystemDictionaryShared')
P4 JDK-8244489 Zero and minimal VM build failure after JDK-8241071 (MetaspaceShared::symbol_space_alloc is undefined)
P4 JDK-8239915 Zero VM crashes when handling dynamic constant
P4 JDK-8244971 Zero VM is broken after JDK-8241825 (COMPRESSED_CLASS_POINTERS_DEPENDS_ON_COMPRESSED_OOPS not defined)
P4 JDK-8244625 Zero VM is broken after JDK-8244550 (java_lang_Class::as_Klass(oopDesc*) undefined)
P4 JDK-8247284 Zero VM is broken after JDK-8244920 ('class JavaFrameAnchor' has no member named 'set_last_Java_sp')

hotspot/svc

Priority Bug Summary
P2 JDK-8243989 test/hotspot/jtreg/serviceability/jvmti/CanGenerateAllClassHook/CanGenerateAllClassHook.java needs to use othervm
P3 JDK-8244571 assert(!_thread->is_pending_jni_exception_check()) failed: Pending JNI Exception Check during class loading
P4 JDK-8242295 Change ThreadMBean in vmTestbase/nsk/monitoring to ThreadMXBean
P4 JDK-8249039 clean up FileInstaller $test.src $cwd in vmTestbase_nsk_aod tests
P4 JDK-8249040 clean up FileInstaller $test.src $cwd in vmTestbase_nsk_jdb tests
P4 JDK-8249035 clean up FileInstaller $test.src $cwd in vmTestbase_nsk_jdwp tests
P4 JDK-8249034 clean up FileInstaller $test.src $cwd in vmTestbase_nsk_jvmti tests
P4 JDK-8249028 clean up FileInstaller $test.src $cwd in vmTestbase_nsk_monitoring tests
P4 JDK-8240691 ClhsdbCDSJstackPrintAll incorrectly thinks CDS is in use
P4 JDK-8236552 Description of jmxremote.ssl.config.file in ManagementAgent.start is incorrect
P4 JDK-8242471 remove "temporarily" restrictions of nsk/jdi/Argument/value/value004
P4 JDK-8234510 Remove file seeking requirement for writing a heap dump
P4 JDK-8244993 Revert changes to OutputAnalyzer stderrShouldBeEmptyIgnoreVMWarnings() that allow version strings
P4 JDK-8243954 serviceability/logging/TestQuotedLogOutputs.java fails after 8243928
P4 JDK-8242313 use reproducible random in hotspot svc tests

hotspot/svc-agent

Priority Bug Summary
P2 JDK-8240956 SEGV in DwarfParser::process_dwarf after JDK-8234624
P3 JDK-8196751 Add jhsdb option to specify debug server RMI connector port
P3 JDK-8235220 ClhsdbScanOops.java fails with sun.jvm.hotspot.types.WrongTypeException
P3 JDK-8242142 convert clhsdb "class" and "classes" commands from javascript to java
P3 JDK-8240990 convert clhsdb "dumpclass" command from javascript to java
P3 JDK-8240989 convert clhsdb "dumpheap" command from javascript to java
P3 JDK-8242162 convert clhsdb "sysprops" command from javascript to java
P3 JDK-8242808 Fix all remaining deprecation warnings in jdk.hotspot.agent
P3 JDK-8242943 Fix all remaining unchecked warnings in jdk.hotspot.agent
P3 JDK-8242804 Fix trivial deprecation issues in jdk.hotspot.agent
P3 JDK-8241618 Fix trivial unchecked warnings for jdk.hotspot.agent
P3 JDK-8242629 Remove references to deprecated java.util.Observer and Observable
P3 JDK-8244668 Remove SA's javascript support
P3 JDK-8204994 SA might fail to attach to process with "Windbg Error: WaitForEvent failed"
P3 JDK-8231634 SA stack walking fails with "illegal bci"
P3 JDK-8242165 SA sysprops support fails to dump all system properties
P3 JDK-8193237 SA: ClhsdbLauncher should show the command being executed
P3 JDK-8243500 SA: Incorrect BCI and Line Number with jstack if the top frame is in the interpreter (BSD and Windows)
P3 JDK-7107012 sun.jvm.hostspot.code.CompressedReadStream readDouble() conversion to long mishandled
P3 JDK-8242787 sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java fails with sun.jvm.hotspot.types.WrongTypeException
P4 JDK-8243206 Cleanup error checking and handling in serviceability/sa/JhsdbThreadInfoTest.java
P4 JDK-8242168 ClhsdbFindPC.java failed due to "RuntimeException: 'In code in NMethod for LingeredAppWithTrivialMain.main' missing from stdout/stderr"
P4 JDK-8243210 ClhsdbScanOops fails with NullPointerException in FileMapHeader.inCopiedVtableSpace
P4 JDK-8237008 Exclude serviceability/sa/TestInstanceKlassSizeForInterface.java on linuxppc64 and linuxppc64le
P4 JDK-8217441 Failure of ::realloc() should be handled correctly in sawindbg.cpp
P4 JDK-8235846 Improve WindbgDebuggerLocal implementation
P4 JDK-8239462 jdk.hotspot.agent misses some ReleaseStringUTFChars calls in case of early returns
P4 JDK-8234624 jstack mixed mode should refer DWARF
P4 JDK-8239224 libproc_impl.c previous_thr may be used uninitialized warning
P4 JDK-8244622 Remove SA's memory/FreeChunk.java. It's no longer used.
P4 JDK-8243450 Remove VMOps from jdk.hotspot.agent
P4 JDK-8230731 SA tests fail with "Windbg Error: ReadVirtual failed"
P4 JDK-8242384 sa/TestSysProps.java failed due to "RuntimeException: Could not find property in jinfo output: [0.058s][info][cds] Archive was created with UseCompressedOops"
P4 JDK-8184249 SA: clhsdb 'intConstant' throws a NullPointerException when not attached to a VM
P4 JDK-8239916 SA: delete dead code in jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
P4 JDK-8194874 SA: Remove scripts with sa-jdi.jar dependencies.
P4 JDK-8243946 serviceability/sa and jvmti tests fail after JDK-8243928
P4 JDK-8242265 serviceability/sa/ClhsdbScanOops.java fails due to bad @requires expression
P4 JDK-8242789 sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java fails with 'JShellToolProvider' missing from stdout/stderr
P4 JDK-8244203 sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java fails with NullPointerException
P4 JDK-8237501 TestInstanceKlassSizeForInstance runs TestInstanceKlassSize instead
P4 JDK-8214797 TestJmapCoreMetaspace.java timed out
P4 JDK-8241320 The ClassLoaderData::_is_unsafe_anonymous field is unused in the SA
P5 JDK-8237250 pmap and pstack should do a better of making it clear that they are not supported on Mac OS X

hotspot/test

Priority Bug Summary
P2 JDK-8247716 JVM_RegisterWhiteBoxMethods checks wrong classloader
P3 JDK-8242931 Few more tests that use nashorn have been missed
P3 JDK-8243154 Fix deprecation warnings in failure handler
P3 JDK-8236111 narrow allowSmartActionArgs disabling
P3 JDK-8242463 ProcessTools.createNativeTestProcessBuilder() in testlib needs jdk/bin on PATH on Windows
P3 JDK-8245610 remove in-tree copy on gtest
P3 JDK-8240904 Screen flashes on test failures when running tests from make
P4 JDK-8236437 [BACKOUT] JDK-8236275 switch to jck14-b09
P4 JDK-8249036 clean up FileInstaller $test.src $cwd in vmTestbase_nsk_stress tests
P4 JDK-8244614 cleanup keywords used/available in hotspot testbase
P4 JDK-8241707 introduce randomness k/w to hotspot test suite
P4 JDK-8240698 LingeredApp does not pass getTestJavaOpts() to the children process if vmArguments is already specified
P4 JDK-8250688 missed open parenthesis for GTEST_FRAMEWORK_SRC var in Main.gmk
P4 JDK-8247725 move two tests for whitebox from test/hotspot/jtreg/sanity to test/lib-test
P4 JDK-8244078 ProcessTools executeTestJvm and createJavaProcessBuilder have inconsistent handling of test.*.opts
P4 JDK-8241123 Refactor vmTestbase stress framework to use j.u.c and make creation of threads more flexible
P4 JDK-8243935 remove copying of s.h.WB$WhiteBoxPermission in hotspot tests
P4 JDK-8245874 requires.extraPropDefns.vmOpts doesn't need -Xbootclasspath/a:bootClasses
P4 JDK-8241456 ThreadRunner shouldn't use Wicket for threads starting synchronization
P4 JDK-8243930 update copyright years
P4 JDK-8243429 use reproducible random in :vmTestbase_nsk_stress
P4 JDK-8241623 use reproducible random in hotspot tests
P4 JDK-8242314 use reproducible random in vmTestbase shared code

infrastructure

Priority Bug Summary
P3 JDK-8238534 Deep sign macOS bundles before bundle archive is being created
P4 JDK-8238943 switch to jtreg 5.0
P4 JDK-8246387 switch to jtreg 5.1
P4 JDK-8235960 Zero should not trigger the deprecation warning for ports

infrastructure/build

Priority Bug Summary
P1 JDK-8244756 Build broken with some awk version after JDK-8244248
P1 JDK-8239566 gtest/GTestWrapper.java fails due to "libstlport.so.1: open failed: No such file or directory"
P2 JDK-8245070 32-bit builds are broken after JDK-8242524
P2 JDK-8246094 [macos] Sound Recording and playback is not working
P2 JDK-8243109 Bootcycle build failures after Nashorn removal
P2 JDK-8249255 Build fails if source code in cygwin home dir
P2 JDK-8244247 Build failures after sjavac cleanup
P2 JDK-8239799 Cross-compilation ARM32/AARCH clientvm builds fails after JDK-8239450
P2 JDK-8240950 Missing AC_SUBST after JDK-8240820
P2 JDK-8244951 Missing entitlements for hardened runtime
P2 JDK-8237914 The test-make target does not fail on test failure
P2 JDK-8240777 Update all nroff manpages for JDK 15 release
P3 JDK-8240228 "make hotspot-ide-project" on Windows creates a Visual Studio project with empty preprocessor defines
P3 JDK-8243510 AbsPathsInImage.java fails on Windows
P3 JDK-8244051 AbsPathsInImage.java still fails on Windows
P3 JDK-8240241 Add support for JCov DiffCoverage to make files
P3 JDK-8239860 Add support for testing the configure script
P3 JDK-8243059 Build fails when --with-vendor-name contains a comma
P3 JDK-8244928 Build log output too verbose after JDK-8244844
P3 JDK-8244930 Building without test failure handler broken after JDK-8244844
P3 JDK-8242863 Bump minimum boot jdk to JDK 14
P3 JDK-8244214 Change to VS2019 for building on Windows at Oracle
P3 JDK-8156967 configure --with-extra-cxxflags doesn't affect hotspot
P3 JDK-8246750 Docs bundle should be published to common dir
P3 JDK-8236714 enable link-time section-gc for linux to remove unused code
P3 JDK-8243665 exploded-image-optimize touches module-info.class in all modules
P3 JDK-8247936 Fix typos in man pages
P3 JDK-8241310 Fix warnings in jdk buildtools
P3 JDK-8245033 Fixes for building in WSL
P3 JDK-8239789 Follow-up on JVM feature rewrite
P3 JDK-8243477 FreeType library check should prefer 64-bit directory
P3 JDK-8237192 Generate stripped/public pdbs on Windows for jdk images
P3 JDK-8238918 idea.sh should work with both mercurial and git repos
P3 JDK-8149110 Introduce DISABLED_WARNINGS for Java compilation
P3 JDK-8149111 Introduce DISABLED_WARNINGS_doclint
P3 JDK-8244757 Introduce SetupTarget in Main.gmk
P3 JDK-8238225 Issues reported after replacing symlink at Contents/MacOS/libjli.dylib with binary
P3 JDK-8244844 javac command line is not re-executable
P3 JDK-8246751 Mac OS build settings should use -O3
P3 JDK-8236469 macOS devkit needs 64-bit SetFile for Catalina
P3 JDK-8237879 make 4.3 breaks build
P3 JDK-8239794 Move -Os from JVM feature 'minimal' to new feature 'opt-size'
P3 JDK-8244093 Move all IDE support into coherent structure in make directory
P3 JDK-8241996 on linux set full relro in the linker flags
P3 JDK-8239450 Overhaul JVM feature handling in configure
P3 JDK-8213185 Properly handle run-test-prebuilt -> test-prebuilt migration
P3 JDK-8238281 Raise minimum gcc version needed to 5.0
P3 JDK-8244044 Refactor phase makefiles to be structured per module
P3 JDK-8244036 Refresh SetupJavaCompilation, and remove support for sjavac
P3 JDK-8245032 Remove exceptions from compare.sh
P3 JDK-8243576 Remove residual reference to nashorn modules in make/CompileJavaModules.gmk
P3 JDK-8246478 Remove src/utils/reorder
P3 JDK-8240820 Replace AC_ARG_ENABLE with UTIL_ARG_ENABLE
P3 JDK-8246435 Replace Javascript implementation of pandoc filters with Java
P3 JDK-8239708 Split basics.m4 into basic.m4 and util.m4
P3 JDK-8244592 Start supporting SOURCE_DATE_EPOCH
P3 JDK-8245287 Start using ModuleWrapper for gensrc as well
P3 JDK-8237042 Switch to JCov build which supports byte code version 59
P3 JDK-8244210 The javac server is never used
P3 JDK-8231572 Use -lobjc instead of -fobjc-link-runtime in libosxsecurity
P3 JDK-8246484 Verify patch at start of COMPARE_BUILD=PATCH run
P3 JDK-8242468 VS2019 build missing vcruntime140_1.dll
P3 JDK-8245093 WSL support broke cygwin toolchain detection
P4 JDK-8245401 AbsPathsInImage.java fails on Windows on jdwp.dll
P4 JDK-8236921 Add build target to produce a JDK image suitable for a Graal/SVM build
P4 JDK-8243634 Add pandoc dependency when building linux-aarch64 at Oracle
P4 JDK-8199138 Add RISC-V support to Zero
P4 JDK-8243988 Added flexibility in build system for unusal hotspot configurations
P4 JDK-8246572 Always pass java.library.path when running micro benchmarks
P4 JDK-8218480 Automatically add -Werror in FLAGS_COMPILER_CHECK_ARGUMENTS
P4 JDK-8245096 Better windows environment output in configure
P4 JDK-8244248 boot-jdk.m4 captures the version line using regex
P4 JDK-8201349 build broken when configured with --with-zlib=bundled on gcc 7.3
P4 JDK-8248135 Build microbenchmarks with --enable-preview
P4 JDK-8244615 build-performance.m4 is not always parsing /proc/cpuinfo correctly
P4 JDK-8243590 Bump boot jdk to JDK 14 on aarch64 at Oracle
P4 JDK-8240947 Change conflicting JVM features from warning to error
P4 JDK-8243591 Change to GCC 9.2 for building Linux/aarch64 at Oracle
P4 JDK-8241721 Change to GCC 9.2 for building on Linux at Oracle
P4 JDK-8243973 Clarify difference between JAVA_OPTIONS and VM_OPTIONS
P4 JDK-8241421 Cleanup handling of jtreg
P4 JDK-8237374 configuring with --with-jvm-variants=minimal,server makes cds disappear in server
P4 JDK-8240259 Disable -Wshift-negative-value warnings
P4 JDK-8244061 Disable jvmci/graal/aot when building linux-aarch64 at Oracle
P4 JDK-8245281 Disabling hotspot gtest builds make it impossible to run tests
P4 JDK-8237566 FindTests.gmk should only include existing TEST.ROOT files
P4 JDK-8241034 Fix a configuring error with "-Xmx2048M: command not found"
P4 JDK-8245119 Fix include path for hotspot-ide-project
P4 JDK-8245041 Fix incorrect output order in configure
P4 JDK-8243982 Fix testing documentation after JDK-8240241
P4 JDK-8246256 GenerateLinkOptData should not mutate the interim or bootstrap JDK
P4 JDK-8245870 GTEST_FRAMEWORK_SRC should go through UTIL_FIXUP_PATH
P4 JDK-8244021 Hide warning from jlink about incubating modules
P4 JDK-8244224 Implementation of JEP 381: Remove the Solaris and SPARC Ports
P4 JDK-8236272 Improve fidelity between contents of default CDS archive and classes loaded at runtime
P4 JDK-8245832 JDK build make-static-libs should build all JDK libraries
P4 JDK-8245168 jlink should not be treated as a "small" tool
P4 JDK-8235997 JMH test runner should quote VM_OPTIONS and JAVA_OPTIONS sent to -jvmArgs
P4 JDK-8240972 macOS codesign fail on macOS 10.13.5 or older
P4 JDK-8244097 make bootcycle-images fails after JDK-8244036
P4 JDK-8241271 Make hotspot build reproducible
P4 JDK-8243985 Make source generation by generatecharacter reproducible
P4 JDK-8218814 make test fails when configured with --with-extra-cflags="-Wformat -Werror=format-security"
P4 JDK-8212986 Make Visual Studio compiler check less strict
P4 JDK-8244945 Mark VS2019 as supported and default
P4 JDK-8238530 OPT_SPEED_SRC list misses some files with cpu-dependend file names
P4 JDK-8219973 Remove "smart javac" (sjavac) support in build system
P4 JDK-8243633 Remove cups dependency when building linux at Oracle
P4 JDK-8236274 remove obsolete -d2Zi+ debug flag in MSVC builds
P4 JDK-8243991 Remove obsolete -XX:ThreadStackSize from java command line
P4 JDK-8244009 Separate -Xdoclint options in CompileJavaModules.gmk
P4 JDK-8245046 SetupTarget incorrect for hotspot-ide-project
P4 JDK-8243656 Shell built-in test in configure depends on help
P4 JDK-8241254 Simplify usage of UTIL_DEPRECATED_ARG_ENABLE
P4 JDK-8236488 Support for configure option --with-native-debug-symbols=internal is impossible on Windows
P4 JDK-8244653 Suppress gcc 9.1 ABI change notes on aarch64
P4 JDK-8239019 testmake fails with FATAL: VCS_TYPE is empty
P4 JDK-8250216 The README need not mention retrieving source code
P4 JDK-8240866 Typo in JDK-8240820 messes up configure --help
P4 JDK-8235532 Update --release 14 symbol information for JDK 14 b27
P4 JDK-8237248 Update --release 14 symbol information for JDK 14 b32
P4 JDK-8235926 Update @jls @jvms taglets to allow inline usage
P4 JDK-8238912 Update devkit for linux-aarch64
P4 JDK-8196875 Update run-test instructions for TEST_MODE
P4 JDK-8238542 When warning about C/C++ compiler mismatch, be clear if this is about build compilers
P5 JDK-8244966 Add .vscode to .hgignore and .gitignore
P5 JDK-8243567 Update download link of jtreg provided by Adoption Group

infrastructure/licensing

Priority Bug Summary
P4 JDK-8244094 Fix Amazon copyright in various test files

other-libs

Priority Bug Summary
P3 JDK-8235903 GCC default -fno-common exposes "multiple definition" link errors

other-libs/other

Priority Bug Summary
P4 JDK-8247274 (test) HexPrinter cleanup
P4 JDK-8247521 (test) jdk/test/lib/hexdump/HexPrinterTest.java fails on windows
P4 JDK-8244066 ClassFileInstaller should be run in driver mode
P4 JDK-8237589 Fix copyright header formatting
P4 JDK-8211977 move testlibrary tests into one place
P4 JDK-8244052 remove copying of s.h.WB$WhiteBoxPermission in test/jdk
P4 JDK-8211290 reorganizing the remaining JDK and JAXP test library classes
P4 JDK-8243010 Test support: Customizable Hex Printer
P4 JDK-8183040 update jdk/test/lib/Platform.java to use NIO file API

performance

Priority Bug Summary
P3 JDK-8243156 Fix deprecation and unchecked warnings in microbenchmark
P3 JDK-8236603 JDK 15 Start-up Performance Tracking

performance/hotspot

Priority Bug Summary
P4 JDK-8245043 Simplified contention benchmark

performance/libraries

Priority Bug Summary
P4 JDK-8234812 Add micros for DatagramChannel send/receive
P4 JDK-8237480 Add micros for DatagramSocket send/receive
P4 JDK-8246251 Adjust HelloClasslist after JDK-8230301
P4 JDK-8238189 Cleanups to AES crypto micros

security-libs

Priority Bug Summary
P5 JDK-8241761 Typos: empty lines in javadoc, inconsistent indents, etc. (security-libs only)

security-libs/java.security

Priority Bug Summary
P2 JDK-8244087 2020-04-24 public suffix list update v ff6fcea
P2 JDK-8240686 70 security tests are failing on Windows due to "Fetch artifact failed"
P2 JDK-8236070 Backout fix for JDK-8234465
P2 JDK-8186143 keytool -ext option doesn't accept wildcards for DNS subject alternative names
P2 JDK-8248505 Unexpected NoSuchAlgorithmException when using secure random impl from BCFIPS provider
P3 JDK-8244683 A TSA server used by tests
P3 JDK-8244565 Accept PKCS #8 with version number 1
P3 JDK-8242060 Add revocation checking to jarsigner
P3 JDK-8242811 AlgorithmId::getDefaultAlgorithmParameterSpec returns incompatible PSSParameterSpec for an RSASSA-PSS key
P3 JDK-8242556 Cannot load RSASSA-PSS public key with non-null params from byte array
P3 JDK-8246613 Choose the default SecureRandom algo based on registration ordering
P3 JDK-8239264 Clearup the legacy ObjectIdentifier constructor from int array
P3 JDK-8242184 Default signature algorithm for an RSASSA-PSS key
P3 JDK-8237219 Disable native SunEC implementation by default
P3 JDK-8242151 Improve OID mapping and reuse among JDK security providers for aliases registration
P3 JDK-8246806 Incorrect copyright header in KeyAgreementTest.java, GroupName.java
P3 JDK-8242897 KeyFactory.generatePublic( x509Spec ) failed with java.security.InvalidKeyException
P3 JDK-8245679 KeyStore cannot probe PKCS12 keystore if BouncyCastle is the top security provider
P3 JDK-8238452 Keytool generates wrong expiration date if validity is set to 2050/01/01
P3 JDK-8242565 Policy initialization issues when the denyAfter constraint is enabled
P3 JDK-8225069 Remove Comodo root certificate that is expiring in May 2020
P3 JDK-8225068 Remove DocuSign root certificate that is expiring in May 2020
P3 JDK-8238448 RSASSA-PSS signature verification fail when using certain odd key sizes
P3 JDK-8237888 security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java fails when checking validity interval
P3 JDK-8243424 Signature and SignatureSpi get parameter methods may return null when unsupported
P3 JDK-8218482 sun/security/krb5/auto/ReplayCachePrecise.java failed - no KrbException thrown
P3 JDK-8237804 sun/security/mscapi tests fail with "Key pair not generated, alias already exists"
P3 JDK-8246709 sun/security/tools/jarsigner/TsacertOptionTest.java compilation failed after JDK-8244683
P3 JDK-8239979 sun/security/tools/keytool/ExtOptionCamelCase.java is not run
P3 JDK-8237218 Support NIST Curves verification in java implementation
P3 JDK-8245134 test/lib/jdk/test/lib/security/KeyStoreUtils.java should allow to specify aliases
P3 JDK-8241960 The SHA3 message digests impl of SUN provider are not thread safe after cloned
P3 JDK-8172404 Tools should warn if weak algorithms are used before restricting them
P4 JDK-8225130 Add exception for expiring Comodo roots to VerifyCACerts test
P4 JDK-8244274 Document the new -revCheck option in jarsigner man page
P4 JDK-8239928 ec/ECDSAJavaVerify.java failed due to timeout
P4 JDK-8234465 Encoded elliptic curve private keys should include the public point
P4 JDK-8234697 Generate sun.security.util.math.intpoly classes during build
P4 JDK-8237962 give better error output for invalid OCSP response intervals in CertPathValidator checks
P4 JDK-8240988 Incorrect copyright header in CertificateValidation.java
P4 JDK-8245151 jarsigner should not raise duplicate warnings on verification
P4 JDK-8238566 java.security.Provider$Service.supportsParameter() is racy
P4 JDK-8238388 libj2gss/NativeFunc.o "multiple definition" link errors with GCC10
P4 JDK-8239094 PKCS#9 ChallengePassword attribute does not allow for the UTF8String type
P4 JDK-8244674 Third-party code version check
P4 JDK-8240552 Update jarsigner and keytool man pages for the legacy algorithms
P4 JDK-8246397 Use KnownOIDs for known OIDs
P4 JDK-8240261 Use make/templates/gpl-cp-header in FieldGen.java

security-libs/javax.crypto

Priority Bug Summary
P2 JDK-8246077 Cloneable test in HmacCore seems questionable
P3 JDK-8166597 Crypto support for the EdDSA Signature Algorithm
P3 JDK-8209632 Develop new tests for EdDSA API
P3 JDK-8199231 JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)
P3 JDK-8238502 sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION
P3 JDK-8172680 Support SHA-3 based Hmac algorithms
P4 JDK-8087327 CipherStream produces new byte array on every update or doFinal operation
P4 JDK-8240983 Incorrect copyright header in Apache Santuario 2.1.3 files
P4 JDK-8216012 Infinite loop in RSA KeyPairGenerator
P4 JDK-8239815 Update ECC legal file

security-libs/javax.crypto:pkcs11

Priority Bug Summary
P2 JDK-8238898 Missing hash characters for header on license file
P3 JDK-8239457 call ReleaseStringUTFChars before early returns in Java_sun_security_pkcs11_wrapper_PKCS11_connect
P3 JDK-8236512 PKCS11 Connection closed after Cipher.doFinal and NoPadding
P4 JDK-8238555 Allow initialization of SunPKCS11 with NSS when there are external FIPS modules in the NSSDB

security-libs/javax.net.ssl

Priority Bug Summary
P2 JDK-8237474 Default SSLEngine should create in server role
P2 JDK-8245686 Ed25519 and Ed448 present in handshake messages
P2 JDK-8236039 JSSE Client does not accept status_request extension in CertificateRequest messages for TLS 1.3
P2 JDK-8239798 SSLSocket closes socket both socket endpoints on a SocketTimeoutException
P3 JDK-8245691 Add EdDSA certificstes to SSLSocketTemplate and CertUtils
P3 JDK-8238560 Cleanup and consolidate algorithms in the jdk.tls.legacyAlgorithms security property
P3 JDK-8242294 JSSE Client does not throw SSLException when an alert occurs during handshaking
P3 JDK-8240193 loadLibrary("osxsecurity") should not be removed
P3 JDK-8215711 Missing key_share extension for (EC)DHE key exchange should alert missing_extension
P3 JDK-8242141 New System Properties to configure the TLS signature schemes
P3 JDK-8241039 Retire the deprecated SSLSession.getPeerCertificateChain() method
P3 JDK-8243029 Rewrite javax/net/ssl/compatibility/Compatibility.java with a flexible interop test framework
P3 JDK-8236464 SO_LINGER option is ignored by SSLSocket in JDK 11
P3 JDK-8240871 SSLEngine handshake status immediately after the handshake can be NOT_HANDSHAKING rather than FINISHED with TLSv1.3
P3 JDK-8246031 SSLSocket.getSession() doesn't close connection for timeout/ interrupts
P3 JDK-8243549 sun/security/ssl/CipherSuite/NamedGroupsWithCipherSuite.java failed with Unsupported signature algorithm: DSA
P3 JDK-8206925 Support the certificate_authorities extension
P4 JDK-8215712 Parsing extension failure may alert decode_error
P4 JDK-8219989 Retire the com.sun.net.ssl.internal.ssl.Provider name
P4 JDK-8242008 SSLSession inconsistencies
P4 JDK-8242929 The values of jdk.tls.namedGroups should not be case-sensitive

security-libs/javax.security

Priority Bug Summary
P3 JDK-8242335 Additional Tests for RSASSA-PSS
P3 JDK-8242330 Arrays should be cloned in several JAAS Callback classes
P3 JDK-8160818 GssKrb5Client violates RFC 4752
P3 JDK-8231508 Remove vague spec from KeyTab::exist on fallback
P3 JDK-8239385 Support the 'canonicalize' setting (krb5.conf) in the Kerberos client
P4 JDK-8236405 Formatting issues in Kerberos debug output
P4 JDK-8191395 policy.allowSystemProperty and policy.expandProperties also apply to JAAS configurations

security-libs/javax.smartcardio

Priority Bug Summary
P3 JDK-8163251 Hard coded loop limit prevents reading of smart card data greater than 8k
P4 JDK-8244151 Update MUSCLE PC/SC-Lite headers to1.8.26

security-libs/javax.xml.crypto

Priority Bug Summary
P3 JDK-8247964 All log0() in com/sun/org/slf4j/internal/Logger.java should be private
P3 JDK-8247907 XMLDsig logging does not work

security-libs/jdk.security

Priority Bug Summary
P3 JDK-8242260 Add forRemoval=true to already deprecated ContentSigner
P3 JDK-8240848 ArrayIndexOutOfBoundsException buf for TextCallbackHandler
P4 JDK-8241888 Mirror jdk.security.allowNonCaAnchor system property with a security one

security-libs/org.ietf.jgss

Priority Bug Summary
P4 JDK-8246640 @systemproperty should be @systemProperty in java.security.jgss

security-libs/org.ietf.jgss:krb5

Priority Bug Summary
P3 JDK-8246193 Possible NPE in ENC-PA-REP search in AS-REQ
P4 JDK-8005819 Support cross-realm MSSFU

specification/language

Priority Bug Summary
P3 JDK-8236893 (IGNORE) Changes to Records specification
P3 JDK-8245674 13.4.2: Discuss binary compatibility of sealed and non-sealed interfaces
P3 JDK-8245546 14.22: Completion of switch statement with switch rules but no default
P3 JDK-8227043 JEP 360: Sealed Classes (Preview)
P3 JDK-8235186 JEP 375: Pattern Matching for instanceof (Second Preview)
P3 JDK-8242303 JEP 384: Records (Second Preview)
P3 JDK-8242149 JLS changes for Text Blocks
P3 JDK-8236734 Records: Do not allow 'final' modifier to be redundantly applied to record components
P3 JDK-8236599 Records: Names of formal parameters in canonical constructors must match the corresponding record component
P4 JDK-8240465 3.10.2: Improve information about min/max FP literals
P4 JDK-7074799 4.2: Adopt IEEE 754-2019 terminology in JLS
P4 JDK-8245557 4.8: Erasure of a type is not always a raw type
P4 JDK-8249015 6.1: Bad formatting for "Naming Conventions"
P4 JDK-8247305 7.5.1: Ignore single-type-import of only top level, not nested, types in same compilation unit
P4 JDK-8231970 8.4.8.2: Static methods of classes shouldn't hide static methods of interfaces
P4 JDK-8245550 9.7.4: Fix illegal examples of "admissible" type annotations
P4 JDK-8246156 JLS changes for Pattern Matching for instanceof (Second Preview)
P4 JDK-8246157 JLS changes for Records (Second Preview)
P4 JDK-8227048 JLS changes for Sealed Classes (Preview)
P4 JDK-8236622 Records: Clarify interaction between records and @SafeVarargs
P4 JDK-8236623 Records: Clarify interaction between records and varargs
P4 JDK-8247628 Records: Specify permitted accessibility of canonical constructor of a private record class

specification/vm

Priority Bug Summary
P3 JDK-8231313 5.4.4: Enhance access control for dynamically-determined nest membership
P4 JDK-8240327 2.8: Adopt IEEE 754-2019 terminology in JVMS
P4 JDK-8236510 4.1: Allow v59.0 class files for Java SE 15
P4 JDK-8246158 JVMS changes for Records (Second Preview)
P4 JDK-8227049 JVMS changes for Sealed Classes (Preview)

tools

Priority Bug Summary
P1 JDK-8251276 JDK-8248299 breaks JDK 15 validate-headers build

tools/jar

Priority Bug Summary
P3 JDK-8230117 remove dead code from jar tool

tools/javac

Priority Bug Summary
P1 JDK-8237214 fix for JDK-8236597 reintroduced wrong subexpression
P2 JDK-8246199 'permits' is a restricted identifier
P2 JDK-8246704 --release => "unknown enum constant PreviewFeature$Feature.TEXT_BLOCKS"
P2 JDK-8246257 Annotated record's vararg type component started to be uncompilable with JDK15b24
P2 JDK-8240964 Compilation error thrown when long literal used with yield
P2 JDK-8239447 compiler error for annotations applied to record components with target METHOD
P2 JDK-8247932 JShell crashes when typing text block
P2 JDK-8238735 NPE compiling lambda expression within conditional expression
P2 JDK-8237601 test/langtools/tools/javac/warnings/MaxDiagsRecompile.java fails after JDK-8237589
P3 JDK-8241798 Allow enums to have more constants
P3 JDK-8242293 allow for local interfaces and enums
P3 JDK-8210649 AssertionError @ jdk.compiler/com.sun.tools.javac.comp.Modules.enter(Modules.java:244)
P3 JDK-8228963 Classes found with implicit permits should be listed in natural (source-file) order
P3 JDK-8242472 Comment for unused PreviewFeature.Feature.TEXT_BLOCKS enum
P3 JDK-8242478 compiler implementation for records (Second Preview)
P3 JDK-8227046 compiler implementation for sealed classes
P3 JDK-8241907 Error when cross compiling with JDK 13, release flag and JFR package
P3 JDK-8241741 Implement Text Blocks as a standard feature in javac
P3 JDK-8239884 implicitly generated SomeRecord::toString does not have the same modifiers as other generated methods
P3 JDK-8236597 issues inferring type annotations on records
P3 JDK-8242802 javac crashes when checking equals and hashCode in unresolvable anonymous class
P3 JDK-8235564 javac crashes while compiling incorrect method invocation with member reference
P3 JDK-8242529 javac defines type annotations incorrectly for record members (constructor and property accessor)
P3 JDK-8246486 javac doesn't allow a subclass to be declared before a sealed superclass with no permits clause
P3 JDK-8236682 Javac generates a redundant FieldRef constant for record fields
P3 JDK-8236210 javac generates wrong annotation for fields generated from record components
P3 JDK-8230827 javac gives inappropriate warning about potentially ambiguous methods
P3 JDK-8243548 Javac incorrectly collects enum fields when verifying switch expression exhaustivness
P3 JDK-8243000 javac only build fails after removal of Nashorn
P3 JDK-8235149 javac parser is too aggressive on ambiguous expressions using identifier: record
P3 JDK-8237450 JDK13 annotation processors not run when a supported annotation type specifies a module
P3 JDK-8245445 Langtools NetBeans ant build broken after JDK-8244093
P3 JDK-8236598 make sure that the compiler issues an error for any modifier applied to record components
P3 JDK-8241312 missing code coverage for records
P3 JDK-8228451 NPE in Attr.java when -XDshould-stop.ifError=FLOW
P3 JDK-8242214 NullPointerException in JDK 14 javac compiling a method reference
P3 JDK-8247849 permits clause of sealed interfaces should not allow parameterized types
P3 JDK-8245842 provide tests for binary compatibility assertions for sealed classes
P3 JDK-8240826 records: mandated members should get the accessibility of the enclosing record type
P3 JDK-8236697 Stack overflow with cyclic hierarchy in class file
P3 JDK-8236824 subtypes of non-sealed types not handled correctly
P3 JDK-8235339 test TargetAnnoCombo.java is failing after new target RECORD_COMPONENT was added
P3 JDK-8236997 tools/javac tests fail with --illegal-access=deny
P3 JDK-8247334 Trees.getScope crashes for annotated local records
P3 JDK-8245153 Unicode encoded double-quoted empty string does not compile
P3 JDK-8244763 Update --release 8 symbol information after JSR 337 MR3
P4 JDK-8235528 Add source 15 and target 15 to javac
P4 JDK-8243417 Clean up com.sun.tools.javac.main.CommandLine
P4 JDK-8236435 Fix typos in javac area
P4 JDK-8243557 Inconvenient span for multi-catch error diagnostics
P4 JDK-8240454 incorrect error message: as of release 13, 'record' is a restricted type name
P4 JDK-8237528 Inefficient compilation of Pattern Matching for instanceof
P4 JDK-8241519 javac crashes with wrong module-info.class in module path
P4 JDK-8243047 javac may crash when processing exits in class initializers
P4 JDK-8241950 JShell could support auto-indent
P4 JDK-8243074 Misplaced and/or duplicate super or this constructor invocation not attributed
P4 JDK-8042742 possible error in Tokens.Token.checkKind() for javac
P4 JDK-8245147 Refactor and improve utility of test/langtools/tools/javac/versions/Versions.java
P4 JDK-8245841 Remove unused com.sun.tools.javac.comp.Modules.XMODULES_PREFIX
P4 JDK-8245786 Scope is wrong for ClassTree representing record
P4 JDK-8240970 Some tests fail when run with JCov
P4 JDK-8238838 spurious error message for compact constructors with throws clause
P4 JDK-8231911 Symbol.packge() NPEs on ModuleSymbols
P4 JDK-8241616 Timestamps on ct.sym entries lead to non-reproducible builds
P4 JDK-8236108 tools/javac/lambda/LambdaParserTest.java timed out
P4 JDK-8248299 two jdeps files miss copyright header
P4 JDK-8245847 Update Profile.java to not require per-release updates
P5 JDK-8239544 Javac does not respect should-stop.ifNoError policy to stop after CompileState PARSE, ENTER and PROCESS

tools/javadoc(tool)

Priority Bug Summary
P2 JDK-8239575 javadoc triggers javac AssertionError for annos on modules
P2 JDK-8243318 New test jdk/javadoc/tool/8224612/OptionsTest.java is failing
P2 JDK-8238259 new tests do not account for Windows file separators
P2 JDK-8236539 Relative link tags in record javadoc don't resolve
P2 JDK-8245981 Upgrade to jQuery 3.5.1
P3 JDK-8242607 -Xdoclint doesn't report missing/unexpected comments
P3 JDK-8177280 @see {@link} syntax should allow generic types
P3 JDK-8218161 [specification] inline tag brace balancing is not documented
P3 JDK-8200363 Add javadoc command line setting to fail on warnings
P3 JDK-8164408 Add module support for @see, @link and @linkplain javadoc tags.
P3 JDK-8238646 Cleanup signature and use of CommentHelper
P3 JDK-8240136 Cleanup/simplify HTML/CSS for definition lists
P3 JDK-8239804 Cleanup/simplify HTML/CSS for general block tags
P3 JDK-8240697 convert builders to high-level Content blocks
P3 JDK-8242532 convert tests to use Text Blocks
P3 JDK-8240916 Convert to using hyphenated naming for CSS classes
P3 JDK-8247788 DocCommentParser should not reject standalone '>'
P3 JDK-8247382 doclint errors (missing comments) in jdk.compiler and jdk.javadoc
P3 JDK-8246712 doclint incorrectly reports some HTML elements as empty
P3 JDK-8247235 doclint should permit "self-closing" tags for void elements in HTML5
P3 JDK-8247955 doclint: don't complain about summary/caption when role=presentation
P3 JDK-8247815 doclint: recategorize "no description for ..." as MISSING, not SYNTAX
P3 JDK-8237826 DocTrees should provide getType(DocTreePath) method
P3 JDK-8239817 Eliminate use of contentContainer and friends
P3 JDK-8241190 Fix name clash for constants-summary CSS class
P3 JDK-8237725 Fix signature of StandardDoclet.getSupportedOptions
P3 JDK-8220002 Improve anchor definitions in generated files
P3 JDK-8242649 improve the CSS class names used for summary and details tables
P3 JDK-8236935 Improve UX of the search control
P3 JDK-8238697 Incorrect Man pages of Javadocs tool
P3 JDK-8241292 Interactive Search results are not highlighted as they used to be
P3 JDK-8236949 javadoc -Xdoclint does not accumulate options correctly
P3 JDK-8246429 Javadoc comparators are not module-aware
P3 JDK-8245696 javadoc crashes when a doc-files directory contains a '#' file
P3 JDK-8240169 javadoc fails to link to docs with non-matching modularity
P3 JDK-8198705 Javadoc search needs a fix to handle duplicate package names in different modules
P3 JDK-8246078 Javadoc Search specification link from Javadoc Help page points to JDK 13 spec
P3 JDK-8224613 javadoc should better handle bad options
P3 JDK-8224612 javadoc should better handle empty set of doclet options
P3 JDK-8224266 Javadoc tool generates an error instead of a warning for missing references
P3 JDK-8222793 Javadoc tool ignores "-locale" param and uses default locale for all messages and texts
P3 JDK-8223536 jdk/javadoc/doclet/MetaTag/MetaTag.java still fails when run across midnight
P3 JDK-8239816 Make handling of module / package / types consistent.
P3 JDK-8237383 Members inherited from non-public types are not included in index
P3 JDK-8242056 Merge support for AnnotationType builders/writers into support for other types
P3 JDK-8243533 Only one of several deprecated overloaded methods listed in the Deprecated list
P3 JDK-8247780 Refine the Help page for API Documentation
P3 JDK-8237909 Remove zipped index files feature
P3 JDK-8237492 Reorganize impl of doclet options
P3 JDK-8237803 Reorganize impl of tool options
P3 JDK-8248409 some jdk/javadoc/doclet tests fail (JDK 15)
P3 JDK-8235306 Support doc-comment tags that can be inline or block tags
P3 JDK-8238437 Support separate locales for console messages and HTML content.
P3 JDK-8240476 SystemPropertiesWriter does not conform to standard page layout
P3 JDK-8241693 The paragraphs in the help page should not be in a
    P3 JDK-8241969 Type annotation is not shown for wildcard type in Javadoc
    P3 JDK-8241544 update stylesheet for *-page CSS class rename and hyphenated naming
    P3 JDK-8236700 Upgrading JSZip to 3.2.2 from 3.1.5
    P3 JDK-8241895 use new "details-list" CSS class instead of general "block-list" for list of details sections
    P3 JDK-8241625 use new "member-list" CSS class instead of general "block-list" for list of members
    P3 JDK-8242326 use new "summary-list" CSS class instead of general "block-list" for list of summary sections
    P3 JDK-8240555 Using env of JAVA_TOOL_OPTIONS and _JAVA_OPTIONS breaks QuietOption.java test
    P4 JDK-8243396 Add a brief description of argfiles to the javadoc help output
    P4 JDK-8239378 Add Classpath Exception to license in source file.
    P4 JDK-8241780 Allow \n@ inside inline tags.
    P4 JDK-8239487 Better links generation for system properties found in HTML files
    P4 JDK-8238467 Clean up annotations on overridden/implemented methods
    P4 JDK-8236077 Clean up the use of modifiers and semicolons
    P4 JDK-8240138 Cleanup HtmlTree
    P4 JDK-8236030 Cleanup use of String.toCharArray
    P4 JDK-8235947 Cleanup/simplify Utils.getBlockTags
    P4 JDK-8239243 Create index structures only if required
    P4 JDK-8239485 Define behavior of the System Properties page when no system properties are available
    P4 JDK-8233293 Doclet examples are inconsistent with documentation
    P4 JDK-8237845 Encapsulate doclet options
    P4 JDK-8236823 Ensure that API documentation uses minified libraries
    P4 JDK-8238291 Fix inconsistencies in the format of the index files
    P4 JDK-8238506 fix obsolete comments and inconsistent exceptions in BaseTaglet
    P4 JDK-8245062 HtmlStyle: group and document members for nav, header, summary, details
    P4 JDK-8241470 HtmlStyle: group and document members: description, flex, signature
    P4 JDK-8239876 Improve SearchIndexItem
    P4 JDK-8247913 Javadoc doc-comment-spec contains unintentional HTML char reference
    P4 JDK-8231484 Javadoc documentation includes unrecognized option -Xmodule:
    P4 JDK-8227047 Javadoc for sealed types
    P4 JDK-8246705 javadoc gives "misleading" and incomplete warning message.
    P4 JDK-8243562 Make display of search results consistent with color scheme
    P4 JDK-8241982 Make TestSearchScript.java run with GraalJS
    P4 JDK-8238969 Miscellaneous cleanup
    P4 JDK-8243388 Moving search result selection clears search input
    P4 JDK-8241631 PropertyGetterTaglet, PropertySetterTaglet may be removed
    P4 JDK-8235447 Remove (obsolete) @author info from javadoc tests
    P4 JDK-8232438 Remove ?is-external=true from external links
    P4 JDK-8238167 Remove stray files from jdk.javadoc
    P4 JDK-8238503 Remove unused field and accessor for docLocale from ToolOptions
    P4 JDK-8238648 Rename and simplify Utils.WeakSoftHashMap
    P4 JDK-8241030 rename HtmlTag to TagName
    P4 JDK-8247577 Stamp the Javadoc Search Specification with the JDK version
    P4 JDK-8240137 Support chained use of Content.add
    P4 JDK-8237472 Typos in Documentation Comment Specification for the Standard Doclet

    tools/javap

    Priority Bug Summary
    P3 JDK-8219475 javap man page needs to be updated
    P4 JDK-8244573 java.lang.ArrayIndexOutOfBoundsException thrown for malformed class file

    tools/jconsole

    Priority Bug Summary
    P3 JDK-8236873 Worker has a deadlock bug

    tools/jlink

    Priority Bug Summary
    P3 JDK-8241602 jlink does not produce reproducible jimage files
    P3 JDK-8240910 jmod rejects duplicate entries in --class-path jars
    P4 JDK-8242846 Bring back test/jdk/tools/jlink/plugins/OrderResourcesPluginTest.java
    P4 JDK-8243117 Cleanups in Java code of module jdk.jlink
    P4 JDK-8242039 Improve jlink VersionPropsPlugin
    P4 JDK-8240333 jmod incorrectly updates .jar and .jmod files during hashing
    P4 JDK-8246034 Remove java.base/share/classes/jdk/internal/jrtfs/jrtfsviewer.js and java.base/share/classes/jdk/internal/jrtfs/jrtls.js
    P4 JDK-8241462 StripNativeDebugSymbols jlink plugin allocates huge arrays
    P4 JDK-8242860 test/jdk/tools/jlink/ModuleNamesOrderTest.java uses nashorn module

    tools/jpackage

    Priority Bug Summary
    P2 JDK-8237490 [macos] Add support notarizing jpackage app-image and dmg
    P2 JDK-8244220 Compiler error in jpackage with VS2019
    P2 JDK-8236134 files missing in putback to JDK-8233270
    P2 JDK-8244634 LoadLibraryW failed from tools/jpackage tests after JDK-8242302
    P2 JDK-8246792 Mac signing tests failed (unsealed contents present in the bundle root)
    P2 JDK-8243587 Missing comma in copyright header
    P3 JDK-8247422 --runtime-image on Mac should work for runtime root
    P3 JDK-8246706 [macos] Allow SigningPackageTest to be built with real certificates
    P3 JDK-8248501 [macos] App created with jpackage on Mac fails with error -10810
    P3 JDK-8248059 [macos] EmptyFolderPackageTest.java failed "hdiutil: create failed - No child processes"
    P3 JDK-8236282 [macos] Find permanent solution to macOS test timeout problem JDK-8235738
    P3 JDK-8242786 [macos] tools/jpackage/share/IconTest.java fails: ABORT trying to dequeue work
    P3 JDK-8236132 Add missing properties to msi installers
    P3 JDK-8219536 Add Option for user defined jlink options
    P3 JDK-8231283 Add support to jpackage to create install Linux packages in /usr hierarchy
    P3 JDK-8236138 Add tests for jmod applications
    P3 JDK-8246244 BasicShortcutHintTest shortcut can not be found
    P3 JDK-8246627 Consolidate app image bundlers
    P3 JDK-8237966 Creating runtime pkg requires --mac-package-identifier
    P3 JDK-8232077 Default behavior should allow downgrade scenario
    P3 JDK-8230933 Default icon is not set for additional launchers
    P3 JDK-8244758 Dmg bundler ignores --install-dir option.
    P3 JDK-8236129 Exe installers have wrong properties
    P3 JDK-8235915 jpackage associations fail when there are spaces in file name or path
    P3 JDK-8247424 jpackage BasicTest.java failed two sub-tests
    P3 JDK-8248254 jpackage fails if app module is in external runtime
    P3 JDK-8248427 jpackage jtreg BasicTest.testTemp() test fails on Windows
    P3 JDK-8247229 jpackage tests failed due to "semop(1): encountered an error: Invalid argument"
    P3 JDK-8233166 jpackage tool skips empty directories
    P3 JDK-8246212 JPKG001-012: application icon is missing in Control Panel Add/Remove
    P3 JDK-8243673 Mac signing process should not use --deep arg.
    P3 JDK-8238692 MacOS runtime Installer issue
    P3 JDK-8246042 Non-ASCII characters are not handled correctly in the native launcher
    P3 JDK-8247418 Only validate the certificates trust if using the default key user name.
    P3 JDK-8237971 Package type for runtime image on macosx
    P3 JDK-8246624 Refactor JLinkBundlerHelper and StandardBundlerParam classes
    P3 JDK-8242302 Refactor jpackage native code
    P3 JDK-8245831 Unify code parsing version strings on Mac and Windows
    P3 JDK-8236125 Windows (MSVC 2013) build fails in jpackage: Need to include strsafe.h after tchar.h
    P3 JDK-8248264 WinUpgradeUUIDTest application is missing in downgrade scenario
    P3 JDK-8244618 WinUpgradeUUIDTest.java fails after JDK-8236518
    P4 JDK-8235954 [dmg] Default DMG background tiff of jpackage not retina ready
    P4 JDK-8235955 [dmg] DMG creation fails without error message if previous DMG was not ejected
    P4 JDK-8241400 [macos] jpackageapplauncher/main.m built using CXXFLAGS_JDKEXE
    P4 JDK-8237769 [macos] Linking libapplauncher.dylib on Mac OS X fails
    P4 JDK-8244576 [macos] Volume icon deleted by osascript for background image
    P4 JDK-8233270 Add support to jtreg helpers to unpack packages
    P4 JDK-8246010 AdditionalLaunchersTest is not enabled, and fails.
    P4 JDK-8233578 Document configurable parameters of msi packages
    P4 JDK-8245788 EmptyFolderPackageTest fails on Windows 10
    P4 JDK-8242155 Enhance automated macos signing tests
    P4 JDK-8235667 IOUtils.copyFile() problems.
    P4 JDK-8233215 jpackage doesn't allow enough flexibility for file type binding
    P4 JDK-8244981 jpackage error due to missing final newline in Debian control file
    P4 JDK-8232935 jpackage failed with NPE whenever --file-associations provided
    P4 JDK-8247353 jtreg tests minor issues clean up
    P4 JDK-8244183 linker error jpackageapplauncher on Windows 32bit
    P4 JDK-8241713 Linux desktop shortcuts with spaces make postinst/prerm fail
    P4 JDK-8244018 No error message for non-existent icon path
    P4 JDK-8237967 No proper error message when --runtime-image points to non-existent path
    P4 JDK-8235833 PosixPlatform.cpp should not include sysctl.h
    P4 JDK-8238947 tools/jpackage tests fail with old rpmbuild versions
    P4 JDK-8238206 Uninstall verification fails due to msiexec exiting before app is uninstall
    P4 JDK-8242865 Usability problems using mac signing in jpackage
    P5 JDK-8246211 [TEST_BUG] JPKG001-007 instruction need to be updated.

    tools/jshell

    Priority Bug Summary
    P2 JDK-8242919 Paste locks up jshell
    P3 JDK-8239536 Can't use `java.util.List` object after importing `java.awt.List`
    P3 JDK-8199646 JShell tests: jdk/jshell/FailOverDirectExecutionControlTest.java failed with java.lang.UnsupportedOperationException
    P3 JDK-8249367 JShell uses 100% of one core all the time
    P3 JDK-8247438 JShell: When FailOverExecutionControlProvider fails the proximal cause is not shown
    P3 JDK-8246353 Sealed types not supported by jshell
    P3 JDK-8237743 test/langtools/jdk/jshell/FailOverExecutionControlTest.java fails No ExecutionControlProvider with name 'nonExistent' and parameter keys: []
    P3 JDK-8241598 Upgrade JLine to 3.14.0
    P3 JDK-8242030 Wrong package declarations in jline classes after JDK-8241598
    P4 JDK-8234896 Tab completion does not work for method references in jshell.

    tools/launcher

    Priority Bug Summary
    P3 JDK-8240629 argfiles parsing broken for argfiles with comment cross 4096 bytes chunk
    P4 JDK-8245600 Clean up libjli
    P4 JDK-8241445 Fix copyrights after JDK-8240629 change
    P4 JDK-8243453 java --describe-module failed with non-ASCII module name under non-UTF8 environment
    P4 JDK-8241638 launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set

    xml

    Priority Bug Summary
    P4 JDK-8248060 small HTML issues in java.xml package-info.java files

    xml/javax.xml.transform

    Priority Bug Summary
    P3 JDK-8237456 Transform filtered through SAX filter mishandles character entities
    P4 JDK-8238183 SAX2StAXStreamWriter cannot deal with comments prior to the root element

    xml/javax.xml.xpath

    Priority Bug Summary
    P4 JDK-8244342 Compilation warnings about unexpected serialization related method signatures.

    xml/jaxp

    Priority Bug Summary
    P3 JDK-8248348 Regression caused by the update to BCEL 6.0
    P4 JDK-8245231 Javadoc for the readObject methods needs to be updated
    P4 JDK-8209774 Refactor shell test javax/xml/jaxp/common/8035437/run.sh to java
    P4 JDK-8235368 Update Commons BCEL to Version 6.4.1
    P4 JDK-8242470 Update Xerces2 Java to Version 2.12.1
    P5 JDK-8237187 Obsolete references to java.sun.com