RELEASE NOTES FOR: 15 ==================================================================================================== Notes generated: Sat Mar 02 21:59:38 CET 2024 Hint: Prefix bug IDs with https://bugs.openjdk.org/browse/ to reach the relevant JIRA entry. JAVA ENHANCEMENT PROPOSALS (JEP): JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA) Implement cryptographic signatures using the Edwards-Curve Digital Signature Algorithm (EdDSA) as described by [RFC 8032](https://tools.ietf.org/html/rfc8032). JEP 360: Sealed Classes (Preview) Enhance the Java programming language with _[sealed classes and interfaces](https://cr.openjdk.java.net/~briangoetz/amber/datum.html)_. Sealed classes and interfaces restrict which other classes or interfaces may extend or implement them. This is a [preview language feature](https://openjdk.java.net/jeps/12) in JDK 15. 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](https://openjdk.java.net/jeps/181), and may be unloaded independently of other classes. 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](http://openjdk.java.net/jeps/335) with the express intent to remove them in a future release. 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](https://openjdk.java.net/projects/loom). This is a follow-on to [JEP 353][1], which already reimplemented the legacy Socket API. JEP 374: Deprecate and Disable Biased Locking Disable biased locking by default, and deprecate all related command-line options. JEP 375: Pattern Matching for instanceof (Second Preview) Enhance the Java programming language with _pattern matching_ for the `instanceof` operator. [Pattern matching](https://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html) allows common logic in a program, namely the conditional extraction of components from objects, to be expressed more concisely and safely. This is a [preview language feature](https://openjdk.java.net/jeps/12) in JDK 15. JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production) Change the Z Garbage Collector from an experimental feature into a product feature. 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. JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector (Production) Change the Shenandoah garbage collector from an experimental feature into a product feature. 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][jep362] with the express intent to remove them in a future release. 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. JEP 384: Records (Second Preview) Enhance the Java programming language with [records][records], which are classes that act as transparent carriers for immutable data. Records can be thought of as _nominal tuples_. This is a [preview language feature](http://openjdk.java.net/jeps/12) in JDK 15. JEP 385: Deprecate RMI Activation for Removal Deprecate the [RMI Activation](https://docs.oracle.com/en/java/javase/14/docs/specs/rmi/activation.html) 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: 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](https://openjdk.java.net/jeps/355) in early 2019 as a follow-on to explorations begun in [JEP 326](https://openjdk.java.net/jeps/326) (Raw String Literals), which was initially targeted to JDK 12 but eventually [withdrawn and did not appear in that release](https://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002402.html). JEP 355 was [targeted to JDK 13 in June 2019](https://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003050.html) as a [preview feature](http://openjdk.java.net/jeps/12). Feedback on JDK 13 suggested that text blocks should be previewed again in JDK 14, with the addition of [two new escape sequences](#New-escape-sequences). Consequently, [JEP 368](https://openjdk.java.net/jeps/368) was [targeted to JDK 14 in November 2019](https://mail.openjdk.java.net/pipermail/jdk-dev/2019-November/003653.html) 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 = "\n" + " \n" + "

Hello, world

\n" + " \n" + "\n"; ``` _Using a "two-dimensional" block of text_ ``` String html = """

Hello, world

"""; ``` ### 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](https://openjdk.java.net/jeps/355), except for the addition of the subsection on [new escape sequences](#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](https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-3.10.5)_ 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](https://docs.oracle.com/javase/specs/jls/se12/html/jls-15.html#jls-15.28) 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](https://docs.oracle.com/javase/specs/jvms/se12/html/jvms-5.html#jvms-5.1-300), just like for [string literals](https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-3.10.5-410). 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](#Motivation) 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 = """ .............. .............. ..............

Hello, world

.............. .............. .............."""; ``` 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 = """ ................. .............. ..............

Hello, world

.... .............. . ................. .............."""; ``` 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: ``` || | | |

Hello, world

| | | || ``` 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_](#Significant-trailing-line-policy) 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 `\` 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 = """

Hello, world

"""; ``` 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) ``` | | |

Hello, world

| | ``` 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 = """

Hello, world

"""; ``` The spaces visualized with dots are considered to be incidental: ``` String html = """ ........ ........ ........

Hello, world

........ ........ ........"""; ``` 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: ``` | | |

Hello, world

| | ``` Finally, suppose the closing delimiter is moved slightly to the _right_ of the content: ``` String html = """

Hello, world

"""; ``` The spaces visualized with dots are considered to be incidental: ``` String html = """ .............. .............. ..............

Hello, world

.............. .............. .............. """; ``` 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: ``` | | |

Hello, world

| | ``` #### 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](https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-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 = """ \r \r

Hello, world

\r \r \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: ``` |\u000D\u000A | \u000D\u000A |

Hello, world

\u000D\u000A | \u000D\u000A |\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 `\` 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 `\` 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 `\` 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](https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/lang/String.html#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](https://stackoverflow.com/questions/878573/java-multiline-string). 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](https://openjdk.java.net/jeps/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](https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-March/001082.html): > 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](https://openjdk.java.net/jeps/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](https://openjdk.java.net/jeps/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: 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 `SSLParameter`s 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](https://openjdk.java.net/jeps/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](https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/net/doc-files/net-properties.html) in the API documentation. core-svc/tools: 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 ` 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: JDK-8239385: Support for canonicalize in krb5.conf The 'canonicalize' flag in the [krb5.conf file][1] is now supported by the JDK Kerberos implementation. When set to *true*, [RFC 6806][2] 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][2] was not explicitly disabled with the *sun.security.krb5.disableReferrals* system or security properties). [1]: https://web.mit.edu/kerberos/krb5-devel/doc/admin/conf_files/krb5_conf.html [2]: https://tools.ietf.org/html/rfc6806 core-libs/java.util:i18n: 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](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: 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](https://openjdk.java.net/jeps/355) in early 2019 as a follow-on to explorations begun in [JEP 326](https://openjdk.java.net/jeps/326) (Raw String Literals), which was initially targeted to JDK 12 but eventually [withdrawn and did not appear in that release](https://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002402.html). JEP 355 was [targeted to JDK 13 in June 2019](https://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003050.html) as a [preview feature](http://openjdk.java.net/jeps/12). Feedback on JDK 13 suggested that text blocks should be previewed again in JDK 14, with the addition of [two new escape sequences](#New-escape-sequences). Consequently, [JEP 368](https://openjdk.java.net/jeps/368) was [targeted to JDK 14 in November 2019](https://mail.openjdk.java.net/pipermail/jdk-dev/2019-November/003653.html) 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 = "\n" + " \n" + "

Hello, world

\n" + " \n" + "\n"; ``` _Using a "two-dimensional" block of text_ ``` String html = """

Hello, world

"""; ``` ### 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](https://openjdk.java.net/jeps/355), except for the addition of the subsection on [new escape sequences](#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](https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-3.10.5)_ 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](https://docs.oracle.com/javase/specs/jls/se12/html/jls-15.html#jls-15.28) 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](https://docs.oracle.com/javase/specs/jvms/se12/html/jvms-5.html#jvms-5.1-300), just like for [string literals](https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-3.10.5-410). 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](#Motivation) 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 = """ .............. .............. ..............

Hello, world

.............. .............. .............."""; ``` 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 = """ ................. .............. ..............

Hello, world

.... .............. . ................. .............."""; ``` 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: ``` || | | |

Hello, world

| | | || ``` 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_](#Significant-trailing-line-policy) 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 `\` 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 = """

Hello, world

"""; ``` 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) ``` | | |

Hello, world

| | ``` 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 = """

Hello, world

"""; ``` The spaces visualized with dots are considered to be incidental: ``` String html = """ ........ ........ ........

Hello, world

........ ........ ........"""; ``` 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: ``` | | |

Hello, world

| | ``` Finally, suppose the closing delimiter is moved slightly to the _right_ of the content: ``` String html = """

Hello, world

"""; ``` The spaces visualized with dots are considered to be incidental: ``` String html = """ .............. .............. ..............

Hello, world

.............. .............. .............. """; ``` 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: ``` | | |

Hello, world

| | ``` #### 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](https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-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 = """ \r \r

Hello, world

\r \r \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: ``` |\u000D\u000A | \u000D\u000A |

Hello, world

\u000D\u000A | \u000D\u000A |\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 `\` 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 `\` 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 `\` 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](https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/lang/String.html#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](https://stackoverflow.com/questions/878573/java-multiline-string). 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](https://openjdk.java.net/jeps/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](https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-March/001082.html): > 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](https://openjdk.java.net/jeps/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](https://openjdk.java.net/jeps/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 `String`s and other `CharSequence`s 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](https://unicode.org/versions/Unicode13.0.0/). security-libs/javax.crypto:pkcs11: 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: 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](https://openjdk.java.net/jeps/355) in early 2019 as a follow-on to explorations begun in [JEP 326](https://openjdk.java.net/jeps/326) (Raw String Literals), which was initially targeted to JDK 12 but eventually [withdrawn and did not appear in that release](https://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002402.html). JEP 355 was [targeted to JDK 13 in June 2019](https://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003050.html) as a [preview feature](http://openjdk.java.net/jeps/12). Feedback on JDK 13 suggested that text blocks should be previewed again in JDK 14, with the addition of [two new escape sequences](#New-escape-sequences). Consequently, [JEP 368](https://openjdk.java.net/jeps/368) was [targeted to JDK 14 in November 2019](https://mail.openjdk.java.net/pipermail/jdk-dev/2019-November/003653.html) 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 = "\n" + " \n" + "

Hello, world

\n" + " \n" + "\n"; ``` _Using a "two-dimensional" block of text_ ``` String html = """

Hello, world

"""; ``` ### 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](https://openjdk.java.net/jeps/355), except for the addition of the subsection on [new escape sequences](#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](https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-3.10.5)_ 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](https://docs.oracle.com/javase/specs/jls/se12/html/jls-15.html#jls-15.28) 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](https://docs.oracle.com/javase/specs/jvms/se12/html/jvms-5.html#jvms-5.1-300), just like for [string literals](https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-3.10.5-410). 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](#Motivation) 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 = """ .............. .............. ..............

Hello, world

.............. .............. .............."""; ``` 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 = """ ................. .............. ..............

Hello, world

.... .............. . ................. .............."""; ``` 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: ``` || | | |

Hello, world

| | | || ``` 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_](#Significant-trailing-line-policy) 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 `\` 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 = """

Hello, world

"""; ``` 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) ``` | | |

Hello, world

| | ``` 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 = """

Hello, world

"""; ``` The spaces visualized with dots are considered to be incidental: ``` String html = """ ........ ........ ........

Hello, world

........ ........ ........"""; ``` 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: ``` | | |

Hello, world

| | ``` Finally, suppose the closing delimiter is moved slightly to the _right_ of the content: ``` String html = """

Hello, world

"""; ``` The spaces visualized with dots are considered to be incidental: ``` String html = """ .............. .............. ..............

Hello, world

.............. .............. .............. """; ``` 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: ``` | | |

Hello, world

| | ``` #### 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](https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-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 = """ \r \r

Hello, world

\r \r \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: ``` |\u000D\u000A | \u000D\u000A |

Hello, world

\u000D\u000A | \u000D\u000A |\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 `\` 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 `\` 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 `\` 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](https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/lang/String.html#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](https://stackoverflow.com/questions/878573/java-multiline-string). 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](https://openjdk.java.net/jeps/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](https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-March/001082.html): > 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](https://openjdk.java.net/jeps/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](https://openjdk.java.net/jeps/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](http://openjdk.java.net/jeps/12) 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: 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](https://unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit950.txt). hotspot/svc-agent: 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 ` is used to specify a RMI connector port number. If a port number is not specified, a random available port is used. 2. `--registryport ` 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 ` 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: 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 JDK-8240654: 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 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, -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: 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=` `com.sun.management.jmxremote.rmi.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=` 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: 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](http://openjdk.java.net/jeps/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](http://openjdk.java.net/jeps/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: 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: 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()](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/security/Signature.html#getParameters()) and [SignatureSpi.engineGetParameters()](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/security/SignatureSpi.html#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: 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 the ```minimum``` 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 `Chronology`and/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: 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: 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](https://openjdk.java.net/jeps/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: - 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. - 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. - 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. 5. 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: 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: 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: 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](https://openjdk.java.net/jeps/355) in early 2019 as a follow-on to explorations begun in [JEP 326](https://openjdk.java.net/jeps/326) (Raw String Literals), which was initially targeted to JDK 12 but eventually [withdrawn and did not appear in that release](https://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002402.html). JEP 355 was [targeted to JDK 13 in June 2019](https://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003050.html) as a [preview feature](http://openjdk.java.net/jeps/12). Feedback on JDK 13 suggested that text blocks should be previewed again in JDK 14, with the addition of [two new escape sequences](#New-escape-sequences). Consequently, [JEP 368](https://openjdk.java.net/jeps/368) was [targeted to JDK 14 in November 2019](https://mail.openjdk.java.net/pipermail/jdk-dev/2019-November/003653.html) 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 = "\n" + " \n" + "

Hello, world

\n" + " \n" + "\n"; ``` _Using a "two-dimensional" block of text_ ``` String html = """

Hello, world

"""; ``` ### 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](https://openjdk.java.net/jeps/355), except for the addition of the subsection on [new escape sequences](#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](https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-3.10.5)_ 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](https://docs.oracle.com/javase/specs/jls/se12/html/jls-15.html#jls-15.28) 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](https://docs.oracle.com/javase/specs/jvms/se12/html/jvms-5.html#jvms-5.1-300), just like for [string literals](https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-3.10.5-410). 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](#Motivation) 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 = """ .............. .............. ..............

Hello, world

.............. .............. .............."""; ``` 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 = """ ................. .............. ..............

Hello, world

.... .............. . ................. .............."""; ``` 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: ``` || | | |

Hello, world

| | | || ``` 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_](#Significant-trailing-line-policy) 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 `\` 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 = """

Hello, world

"""; ``` 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) ``` | | |

Hello, world

| | ``` 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 = """

Hello, world

"""; ``` The spaces visualized with dots are considered to be incidental: ``` String html = """ ........ ........ ........

Hello, world

........ ........ ........"""; ``` 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: ``` | | |

Hello, world

| | ``` Finally, suppose the closing delimiter is moved slightly to the _right_ of the content: ``` String html = """

Hello, world

"""; ``` The spaces visualized with dots are considered to be incidental: ``` String html = """ .............. .............. ..............

Hello, world

.............. .............. .............. """; ``` 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: ``` | | |

Hello, world

| | ``` #### 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](https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-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 = """ \r \r

Hello, world

\r \r \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: ``` |\u000D\u000A | \u000D\u000A |

Hello, world

\u000D\u000A | \u000D\u000A |\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 `\` 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 `\` 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 `\` 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](https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/lang/String.html#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](https://stackoverflow.com/questions/878573/java-multiline-string). 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](https://openjdk.java.net/jeps/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](https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-March/001082.html): > 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](https://openjdk.java.net/jeps/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](https://openjdk.java.net/jeps/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: 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: 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 `InflaterOutputStream `constructor, it will default to 512 bytes. core-libs/java.rmi: 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](http://openjdk.java.net/jeps/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: 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](http://openjdk.java.net/jeps/335) 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](http://openjdk.java.net/jeps/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](http://openjdk.java.net/jeps/200#Design-principles) 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](http://openjdk.java.net/jeps/335) 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](http://openjdk.java.net/jeps/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](http://openjdk.java.net/jeps/200#Design-principles) 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: 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: 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: 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: 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: 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): 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: 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](https://openjdk.java.net/jeps/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 ALL FIXED ISSUES, BY COMPONENT AND PRIORITY: client-libs: (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: (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: (P4) JDK-8237746: Fixing compiler warnings in src/demo/share/jfc client-libs/java.awt: (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: (P3) JDK-8239583: [AIX] simplify the native references in X input methods client-libs/javax.accessibility: (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: (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: (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: (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:
  (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:
  (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:
  (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:
  (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:
  (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:
  (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:
  (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:
  (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:
  (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:
  (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:
  (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:
  (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:
  (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:
  (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:
  (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:
  (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:
  (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:
  (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:
  (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:
  (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:
  (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:
  (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:
  (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:
  (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:
  (P2) JDK-8235961: Default javax.sql.rowset.spi.SyncResolver impl returned by SyncProviderException throws unspecified NPE, UOE

core-libs/jdk.nashorn:
  (P2) JDK-8247956: remove scripts under bin/nashorn and doc/nashorn/source
  (P3) JDK-8241749: Remove the Nashorn JavaScript Engine

core-svc/debugger:
  (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:
  (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:
  (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:
  (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:
  (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:
  (P3) JDK-8243648: Windows 32bit compile error src/jdk.incubator.jpackage/windows/native/libjpackage/VersionInfo.cpp

docs/guides:
  (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:
  (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:
  (P2) JDK-8236856: AArch64: Spurious GCC warnings
  (P4) JDK-8244170: [aarch64] correct instruction typo for dcps1/2/3 
  (P4) JDK-8245986: AArch64: Provide information when hitting a HaltNode
  (P4) JDK-8241787: JEP 381: Remove the Solaris and SPARC Ports
  (P4) JDK-8234599: PPC64: Add support on recent CPUs and Linux for JEP-352

hotspot/compiler:
  (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-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-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:
  (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:
  (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:
  (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/runtime:
  (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-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:
  (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:
  (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:
  (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:
  (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:
  (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:
  (P4) JDK-8244094: Fix Amazon copyright in various test files

other-libs:
  (P3) JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors

other-libs/other:
  (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:
  (P3) JDK-8243156: Fix deprecation and unchecked warnings in microbenchmark
  (P3) JDK-8236603: JDK 15 Start-up Performance Tracking

performance/hotspot:
  (P4) JDK-8245043: Simplified contention benchmark

performance/libraries:
  (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:
  (P5) JDK-8241761: Typos: empty lines in javadoc, inconsistent indents, etc. (security-libs only)

security-libs/java.security:
  (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:
  (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:
  (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:
  (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:
  (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:
  (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:
  (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:
  (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:
  (P4) JDK-8246640: @systemproperty should be @systemProperty in java.security.jgss

security-libs/org.ietf.jgss:krb5:
  (P3) JDK-8246193: Possible NPE in ENC-PA-REP search in AS-REQ
  (P4) JDK-8005819: Support cross-realm MSSFU

specification/language:
  (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:
  (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:
  (P1) JDK-8251276: JDK-8248299 breaks JDK 15 validate-headers build

tools/jar:
  (P3) JDK-8230117: remove dead code from jar tool

tools/javac:
  (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):
  (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: (P3) JDK-8219475: javap man page needs to be updated (P4) JDK-8244573: java.lang.ArrayIndexOutOfBoundsException thrown for malformed class file tools/jconsole: (P3) JDK-8236873: Worker has a deadlock bug tools/jlink: (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: (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: (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: (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: (P4) JDK-8248060: small HTML issues in java.xml package-info.java files xml/javax.xml.transform: (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: (P4) JDK-8244342: Compilation warnings about unexpected serialization related method signatures. xml/jaxp: (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