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 `\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 \rHello, 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 `\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 `\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 \rHello, 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 `\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 `\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 \rHello, 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 `\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 `\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 \rHello, 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 `\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 `\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 \rHello, 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 `\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 `\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 \rHello, 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 `\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 `\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 \rHello, 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 `\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 `\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 \rHello, 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 `\ 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 for JDK 15
(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-8239383: Support for Unicode 13.0
(P3) JDK-8247444: Trust final fields in records
(P3) JDK-8217475: Unexpected StackOverflowError in "process reaper" thread
(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 time-zone 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: Support for CLDR version 37
(P3) JDK-8241082: Upgrade IANA Language Subtag Registry data to 03-16-2020 version
(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-8243210: ClhsdbScanOops fails with NullPointerException in FileMapHeader.inCopiedVtableSpace
(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-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-8233619: 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 to the latest release 1.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 from v3.1.5 to v3.2.2
(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-8242859: test/jdk/tools/jlink/JLinkTest.java uses nashorn module
(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 BCEL to Version 6.4.1
(P4) JDK-8242470: Update Xerces to Version 2.12.1
(P5) JDK-8237187: Obsolete references to java.sun.com