RELEASE NOTES FOR: 15
====================================================================================================
Notes generated: Thu Jul 01 07:18:25 CEST 2021
JIRA Query:
project = JDK AND (status in (Closed, Resolved)) AND (resolution not in ("Won't Fix", Duplicate,
"Cannot Reproduce", "Not an Issue", Withdrawn)) AND (labels not in (release-note, testbug,
openjdk-na, testbug) OR labels is EMPTY) AND (summary !~ 'testbug') AND (summary !~ 'problemlist')
AND (summary !~ 'problem list') AND (summary !~ 'release note') AND (issuetype != CSR) AND
fixVersion = 15
Acquiring pages (2306 total): ............................................... done
Loading issues (2306 total): ............................................... done
Resolving issues (2306 total): .............................................. done
Resolving parents (2306 total): .............................................. done
Resolving backports (2306 total): .............................................. done
JIRA Query:
project = JDK AND issuetype = JEP AND fixVersion = 15 ORDER BY summary ASC
Acquiring pages (14 total): . done
Loading issues (14 total): . done
Resolving issues (14 total): done
Resolving parents (14 total): done
Filtered 197 issues carried over, 2104 pushes left.
Hint: Prefix bug IDs with https://bugs.openjdk.java.net/browse/ to reach the relevant JIRA entry.
JAVA ENHANCEMENT PROPOSALS (JEP):
JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)
Implement cryptographic signatures using the Edwards-Curve Digital Signature Algorithm (EdDSA) as
described by [RFC 8032](https://tools.ietf.org/html/rfc8032).
JEP 360: Sealed Classes (Preview)
Enhance the Java programming language with _[sealed classes and
interfaces](https://cr.openjdk.java.net/~briangoetz/amber/datum.html)_. Sealed classes and
interfaces restrict which other classes or interfaces may extend or implement them.
JEP 371: Hidden Classes
Introduce _hidden classes_, which are classes that cannot be used directly by the bytecode of other
classes. Hidden classes are intended for use by frameworks that generate classes at run time and use
them indirectly, via reflection. A hidden class may be defined as a member of an [access control
nest](https://openjdk.java.net/jeps/181), and may be unloaded independently of other classes.
JEP 372: Remove the Nashorn JavaScript Engine
Remove the Nashorn JavaScript script engine and APIs, and the `jjs` tool. The engine, the APIs, and
the tool were [deprecated for removal in Java 11](http://openjdk.java.net/jeps/335) with the express
intent to remove them in a future release.
JEP 373: Reimplement the Legacy DatagramSocket API
Replace the underlying implementations of the `java.net.DatagramSocket` and
`java.net.MulticastSocket` APIs with simpler and more modern implementations that are easy to
maintain and debug. The new implementations will be easy to adapt to work with virtual threads,
currently being explored in [Project Loom](https://openjdk.java.net/projects/loom). This is a
follow-on to [JEP 353][1], which already reimplemented the legacy Socket API.
JEP 374: Disable and Deprecate Biased Locking
Disable biased locking by default, and deprecate all related command-line options.
JEP 375: Pattern Matching for instanceof (Second Preview)
Enhance the Java programming language with _pattern matching_ for the `instanceof` operator.
[Pattern matching](https://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html) allows common
logic in a program, namely the conditional extraction of components from objects, to be expressed
more concisely and safely. This is a [preview language feature](https://openjdk.java.net/jeps/12) in
JDK 15.
JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production)
Change the Z Garbage Collector from an experimental feature into a product feature.
JEP 378: Text Blocks
Add _text blocks_ to the Java language. A text block is a multi-line string literal that avoids the
need for most escape sequences, automatically formats the string in a predictable way, and gives the
developer control over the format when desired.
JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector (Production)
Change the Shenandoah garbage collector from an experimental feature into a product feature.
JEP 381: Remove the Solaris and SPARC Ports
Remove the source code and build support for the Solaris/SPARC, Solaris/x64, and Linux/SPARC ports.
These ports were [deprecated for removal in JDK 14][jep362] with the express intent to remove them
in a future release.
JEP 383: Foreign-Memory Access API (Second Incubator)
Introduce an API to allow Java programs to safely and efficiently access foreign memory outside of
the Java heap.
JEP 384: Records (Second Preview)
Enhance the Java programming language with [records][records], which are classes that act as
transparent carriers for immutable data. Records can be thought of as _nominal tuples_.
JEP 385: Deprecate RMI Activation for Removal
Deprecate the [RMI
Activation](https://docs.oracle.com/en/java/javase/14/docs/specs/rmi/activation.html) mechanism for
future removal. RMI Activation is an obsolete part of RMI that has been optional since Java 8. No
other part of RMI will be deprecated.
RELEASE NOTES, BY COMPONENT:
client-libs:
JDK-8252738: Windows GDI API's memory restrictions
It has been found that some Windows GDI functions don't support all types of Java heap memory
allocation schemes. This problem can cause repaint issues and printing bugs. Affected JVM
flags: -XX:+UseLargePages, -XX:+UseNUMAInterleaving, and -XX:+UseZGC. The problem can be
worked around by turning off the listed flags.
See:
https://support.microsoft.com/en-us/help/4567569/gdi-apis-may-fail-when-large-pages-or-vad-spanning-is-used
JDK-8252939: Windows GDI API's memory restrictions
It has been found that some Windows GDI functions don't support all types of Java heap memory
allocation schemes. This problem can cause repaint issues and printing bugs. Affected JVM
flags: -XX:+UseLargePages and -XX:+UseNUMAInterleaving. The problem can be worked around by
turning off the listed flags.
See:
https://support.microsoft.com/en-us/help/4567569/gdi-apis-may-fail-when-large-pages-or-vad-spanning-is-used
JDK-8252735: Workaround for Windows GDI API's memory restrictions
It has been found that some Windows GDI functions don't support all types of Java heap memory
allocation schemes. This problem can cause repaint issues and printing bugs. It has been
worked around by allocating temporary buffers off heap.
See:
https://support.microsoft.com/en-us/help/4567569/gdi-apis-may-fail-when-large-pages-or-vad-spanning-is-used
client-libs/java.awt:
JDK-8236543: java.awt.Robot.delay() Method Completes With Interrupt Status Set When Interrupted
When it is interrupted, the implementation of the `java.awt.Robot.delay()` method has been
changed to complete with the interrupt status set.
If a thread is interrupted while waiting in the `java.awt.Robot.delay()` method, then this
method returns immediately with the interrupt status set. If the interrupted status is already
set, this method returns immediately with the interrupt status set.
core-libs/java.lang:
JDK-8251953: Added isEmpty Default Method to CharSequence
`java.lang.CharSequence` has been updated in this release to define a default `isEmpty` method
that tests if a character sequence is empty. Testing for, and filtering out, empty `String`s
and other `CharSequence`s is a common occurrence in code and `CharSequence::isEmpty` can be
used as a method reference. Classes that implement `java.lang.CharSequence` and another
interface that defines `isEmpty` method should be aware of this addition as they may need to
be modified to override the `isEmpty` method.
JDK-8251556: Optimized Empty Substring Handling
The implementation of `String.substring` and related methods `stripLeading` and
`stripTrailing` have changed in this release to avoid redundantly creating a new empty String.
This may impact code that depends on unspecified behaviour and the identity of empty
sub-strings.
JDK-8236934: JEP 378: Text Blocks
Summary -------
Add _text blocks_ to the Java language. A text block is a multi-line string literal that
avoids the need for most escape sequences, automatically formats the string in a predictable
way, and gives the developer control over the format when desired.
History -------
Text blocks were proposed by [JEP 355](https://openjdk.java.net/jeps/355) in early 2019 as a
follow-on to explorations begun in [JEP 326](https://openjdk.java.net/jeps/326) (Raw String
Literals), which was initially targeted to JDK 12 but eventually [withdrawn and did not appear
in that release](https://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002402.html).
JEP 355 was [targeted to JDK 13 in June
2019](https://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003050.html) as a [preview
feature](http://openjdk.java.net/jeps/12). Feedback on JDK 13 suggested that text blocks
should be previewed again in JDK 14, with the addition of [two new escape
sequences](#New-escape-sequences). Consequently, [JEP 368](https://openjdk.java.net/jeps/368)
was [targeted to JDK 14 in November
2019](https://mail.openjdk.java.net/pipermail/jdk-dev/2019-November/003653.html) as a preview
feature. Feedback on JDK 14 suggested that text blocks were ready to become final and
permanent in JDK 15 with no further changes.
Goals -----
- Simplify the task of writing Java programs by making it easy to express strings that span
several lines of source code, while avoiding escape sequences in common cases.
- Enhance the readability of strings in Java programs that denote code written in non-Java
languages.
- Support migration from string literals by stipulating that any new construct can express the
same set of strings as a string literal, interpret the same escape sequences, and be
manipulated in the same ways as a string literal.
- Add escape sequences for managing explicit white space and newline control.
Non-Goals ---------
- It is not a goal to define a new reference type, distinct from `java.lang.String`, for the
strings expressed by any new construct.
- It is not a goal to define new operators, distinct from `+`, that take `String` operands.
- Text blocks do not directly support string interpolation. Interpolation may be considered in
a future JEP. In the meantime, the new instance method `String::formatted` aids in situations
where interpolation might be desired.
- Text blocks do not support raw strings, that is, strings whose characters are not processed
in any way.
Motivation ----------
In Java, embedding a snippet of HTML, XML, SQL, or JSON in a string literal `"..."` usually
requires significant editing with escapes and concatenation before the code containing the
snippet will compile. The snippet is often difficult to read and arduous to maintain.
More generally, the need to denote short, medium, and long blocks of text in a Java program is
near universal, whether the text is code from other programming languages, structured text
representing golden files, or messages in natural languages. On the one hand, the Java
language recognizes this need by allowing strings of unbounded size and content; on the other
hand, it embodies a design default that strings should be small enough to denote on a single
line of a source file (surrounded by " characters), and simple enough to escape easily. This
design default is at odds with the large number of Java programs where strings are too long to
fit comfortably on a single line.
Accordingly, it would improve both the readability and the writability of a broad class of
Java programs to have a linguistic mechanism for denoting strings more literally than a string
literal -- across multiple lines and without the visual clutter of escapes. In essence, a
two-dimensional block of text, rather than a one-dimensional sequence of characters.
Still, it is impossible to predict the role of every string in Java programs. Just because a
string spans multiple lines of source code does not mean that newline characters are desirable
in the string. One part of a program may be more readable when strings are laid out over
multiple lines, but the embedded newline characters may change the behavior of another part of
the program. Accordingly, it would be helpful if the developer had precise control over where
newlines appear, and, as a related matter, how much white space appears to the left and right
of the "block" of text.
### HTML example
_Using "one-dimensional" string literals_
``` String html = "\n" + " \n" + " Hello,
world
\n" + " \n" + "\n"; ```
_Using a "two-dimensional" block of text_
``` String html = """
Hello, world
"""; ```
### SQL example
_Using "one-dimensional" string literals_
``` String query = "SELECT \"EMP_ID\", \"LAST_NAME\" FROM \"EMPLOYEE_TB\"\n" +
"WHERE \"CITY\" = 'INDIANAPOLIS'\n" + "ORDER BY \"EMP_ID\", \"LAST_NAME\";\n";
```
_Using a "two-dimensional" block of text_
``` String query = """ SELECT "EMP_ID", "LAST_NAME" FROM "EMPLOYEE_TB"
WHERE "CITY" = 'INDIANAPOLIS' ORDER BY "EMP_ID", "LAST_NAME";
"""; ```
### Polyglot language example
_Using "one-dimensional" string literals_
``` ScriptEngine engine = new ScriptEngineManager().getEngineByName("js"); Object obj =
engine.eval("function hello() {\n" + " print('\"Hello,
world\"');\n" + "}\n" + "\n" +
"hello();\n"); ```
_Using a "two-dimensional" block of text_
``` ScriptEngine engine = new ScriptEngineManager().getEngineByName("js"); Object obj =
engine.eval(""" function hello() {
print('"Hello, world"'); }
hello(); """); ```
Description -----------
> _This section is identical to the same section in this JEP's predecessor, [JEP
355](https://openjdk.java.net/jeps/355), except for the addition of the subsection on [new
escape sequences](#New-escape-sequences)._
A _text block_ is a new kind of literal in the Java language. It may be used to denote a
string anywhere that a _[string
literal](https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-3.10.5)_ could
appear, but offers greater expressiveness and less accidental complexity.
A text block consists of zero or more content characters, enclosed by opening and closing
delimiters.
The _opening delimiter_ is a sequence of three double quote characters (`"""`) followed by
zero or more white spaces followed by a line terminator. The _content_ begins at the first
character after the line terminator of the opening delimiter.
The _closing delimiter_ is a sequence of three double quote characters. The content ends at
the last character before the first double quote of the closing delimiter.
The content may include double quote characters directly, unlike the characters in a string
literal. The use of `\"` in a text block is permitted, but not necessary or recommended. Fat
delimiters (`"""`) were chosen so that `"` characters could appear unescaped, and also to
visually distinguish a text block from a string literal.
The content may include line terminators directly, unlike the characters in a string literal.
The use of `\n` in a text block is permitted, but not necessary or recommended. For example,
the text block:
``` """ line 1 line 2 line 3 """ ```
is equivalent to the string literal:
``` "line 1\nline 2\nline 3\n" ```
or a concatenation of string literals:
``` "line 1\n" + "line 2\n" + "line 3\n" ```
If a line terminator is not required at the end of the string, then the closing delimiter can
be placed on the last line of content. For example, the text block:
``` """ line 1 line 2 line 3""" ```
is equivalent to the string literal:
``` "line 1\nline 2\nline 3" ```
A text block can denote the empty string, although this is not recommended because it needs
two lines of source code:
``` String empty = """ """; ```
Here are some examples of ill-formed text blocks:
``` String a = """"""; // no line terminator after opening delimiter String b = """ """; //
no line terminator after opening delimiter String c = """ "; // no closing
delimiter (text block continues to EOF) String d = """ abc \ def """;
// unescaped backslash (see below for escape processing) ```
### Compile-time processing
A text block is a [constant
expression](https://docs.oracle.com/javase/specs/jls/se12/html/jls-15.html#jls-15.28) of type
`String`, just like a string literal. However, unlike a string literal, the content of a text
block is processed by the Java compiler in three distinct steps:
1. Line terminators in the content are translated to LF (`\u000A`). The purpose of this
translation is to follow the principle of least surprise when moving Java source code across
platforms.
2. Incidental white space surrounding the content, introduced to match the indentation of Java
source code, is removed.
3. Escape sequences in the content are interpreted. Performing interpretation as the final
step means developers can write escape sequences such as `\n` without them being modified or
deleted by earlier steps.
The processed content is recorded in the `class` file as a `CONSTANT_String_info` entry in the
constant pool, just like the characters of a string literal. The `class` file does not record
whether a `CONSTANT_String_info` entry was derived from a text block or a string literal.
At run time, a text block is evaluated to an instance of `String`, just like a string literal.
Instances of `String` that are derived from text blocks are indistinguishable from instances
derived from string literals. Two text blocks with the same processed content will refer to
the same instance of `String` due to
[interning](https://docs.oracle.com/javase/specs/jvms/se12/html/jvms-5.html#jvms-5.1-300), just
like for [string
literals](https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-3.10.5-410).
The following sections discuss compile-time processing in more detail.
#### 1. Line terminators
Line terminators in the content are _normalized_ from CR (`\u000D`) and CRLF (`\u000D\u000A`)
to LF (`\u000A`) by the Java compiler. This ensures that the string derived from the content
is equivalent across platforms, even if the source code has been translated to a platform
encoding (see `javac -encoding`).
For example, if Java source code that was created on a Unix platform (where the line
terminator is LF) is edited on a Windows platform (where the line terminator is CRLF), then
without normalization, the content would become one character longer for each line. Any
algorithm that relied on LF being the line terminator might fail, and any test that needed to
verify string equality with `String::equals` would fail.
The escape sequences `\n` (LF), `\f` (FF), and `\r` (CR) are _not_ interpreted during
normalization; escape processing happens later.
#### 2. Incidental white space
The text blocks [shown above](#Motivation) were easier to read than their concatenated string
literal counterparts, but the obvious interpretation for the content of a text block would
include the spaces added to indent the embedded string so that it lines up neatly with the
opening delimiter. Here is the HTML example using dots to visualize the spaces that the
developer added for indentation:
``` String html = """ .............. .............. ..............
Hello, world
.............. .............. .............."""; ```
Since the opening delimiter is generally positioned to appear on the same line as the
statement or expression which consumes the text block, there is no real significance to the
fact that 14 visualized spaces start each line. Including those spaces in the content would
mean the text block denotes a string different from the one denoted by the concatenated string
literals. This would hurt migration, and be a recurring source of surprise: it is
overwhelmingly likely that the developer does _not_ want those spaces in the string. Also, the
closing delimiter is generally positioned to align with the content, which further suggests
that the 14 visualized spaces are insignificant.
Spaces may also appear at the end of each line, especially when a text block is populated by
copy-pasting snippets from other files (which may themselves have been formed by copy-pasting
from yet more files). Here is the HTML example reimagined with some trailing white space,
again using dots to visualize spaces:
``` String html = """ ................. .............. ..............
Hello, world
.... .............. . ................. ..............""";
```
Trailing white space is most often unintentional, idiosyncratic, and insignificant. It is
overwhelmingly likely that the developer does not care about it. Trailing white space
characters are similar to line terminators, in that both are invisible artifacts of the source
code editing environment. With no visual guide to the presence of trailing white space
characters, including them in the content would be a recurring source of surprise, as it would
affect the length, hash code, etc, of the string.
Accordingly, an appropriate interpretation for the content of a text block is to differentiate
_incidental white space_ at the start and end of each line, from _essential white space_. The
Java compiler processes the content by removing incidental white space to yield what the
developer intended. `String::indent` can then be used to further manipulate indentation if
desired. Using `|` to visualize margins:
``` || | | | Hello, world
| | | || ```
The _re-indentation algorithm_ takes the content of a text block whose line terminators have
been normalized to LF. It removes the same amount of white space from each line of content
until at least one of the lines has a non-white space character in the leftmost position. The
position of the opening `"""` characters has no effect on the algorithm, but the position of
the closing `"""` characters does have an effect if placed on its own line. The algorithm is
as follows:
1. Split the content of the text block at every LF, producing a list of _individual lines_.
Note that any line in the content which was just an LF will become an empty line in the list
of individual lines.
2. Add all _non-blank_ lines from the list of individual lines into a set of _determining
lines_. (Blank lines -- lines that are empty or are composed wholly of white space -- have no
visible influence on the indentation. Excluding blank lines from the set of determining lines
avoids throwing off step 4 of the algorithm.)
3. If the last line in the list of individual lines (i.e., the line with the closing
delimiter) is _blank_, then add it to the set of determining lines. (The indentation of the
closing delimiter should influence the indentation of the content as a whole -- a
[_significant trailing line_](#Significant-trailing-line-policy) policy.)
4. Compute the _common white space prefix_ of the set of determining lines, by counting the
number of leading white space characters on each line and taking the minimum count.
5. Remove the common white space prefix from each _non-blank_ line in the list of individual
lines.
6. Remove all trailing white space from all lines in the modified list of individual lines
from step 5. This step collapses wholly-white-space lines in the modified list so that they
are empty, but does not discard them.
7. Construct the result string by joining all the lines in the modified list of individual
lines from step 6, using LF as the separator between lines. If the final line in the list from
step 6 is empty, then the joining LF from the previous line will be the last character in the
result string.
The escape sequences `\b` (backspace), `\t` (tab) and `\s` (space) are _not_ interpreted by
the algorithm; escape processing happens later. Similarly, the `\` escape
sequence does not prevent the splitting of lines on the line-terminator since the sequence is
treated as two separate characters until escape processing.
The re-indentation algorithm will be normative in _The Java Language Specification_.
Developers will have access to it via `String::stripIndent`, a new instance method.
#### Significant trailing line policy
Normally, one would format a text block in two ways: first, position the left edge of the
content to appear under the first `"` of the opening delimiter, and second, place the closing
delimiter on its own line to appear exactly under the opening delimiter. The resulting string
will have no white space at the start of any line, and will not include the trailing blank
line of the closing delimiter.
However, because the trailing blank line is considered a _determining line_, moving it to the
left has the effect of reducing the common white space prefix, and therefore reducing the the
amount of white space that is stripped from the start of every line. In the extreme case,
where the closing delimiter is moved all the way to the left, that reduces the common white
space prefix to zero, effectively opting out of white space stripping.
For example, with the closing delimiter moved all the way to the left, there is no incidental
white space to visualize with dots:
``` String html = """
Hello, world
"""; ```
Including the trailing blank line with the closing delimiter, the common white space prefix is
zero, so zero white space is removed from the start of each line. The algorithm thus produces:
(using `|` to visualize the left margin)
``` | | | Hello, world
| | ```
Alternatively, suppose the closing delimiter is not moved all the way to the left, but rather
under the `t` of `html` so it is eight spaces deeper than the variable declaration:
``` String html = """
Hello, world
"""; ```
The spaces visualized with dots are considered to be incidental:
``` String html = """ ........ ........ ........
Hello, world
........ ........ ........"""; ```
Including the trailing blank line with the closing delimiter, the common white space prefix is
eight, so eight white spaces are removed from the start of each line. The algorithm thus
preserves the essential indentation of the content relative to the closing delimiter:
``` | | | Hello, world
| |
```
Finally, suppose the closing delimiter is moved slightly to the _right_ of the content:
``` String html = """
Hello, world
"""; ```
The spaces visualized with dots are considered to be incidental:
``` String html = """ .............. .............. ..............
Hello, world
.............. .............. .............. """; ```
The common white space prefix is 14, so 14 white spaces are removed from the start of each
line. The trailing blank line is stripped to leave an empty line, which being the last line is
then discarded. In other words, moving the closing delimiter to the right of the content has
no effect, and the algorithm again preserves the essential indentation of the content:
``` | | | Hello, world
| | ```
#### 3. Escape sequences
After the content is re-indented, any _escape sequences_ in the content are interpreted. Text
blocks support all of the escape sequences supported in string literals, including `\n`, `\t`,
`\'`, `\"`, and `\\`. See [section
3.10.6](https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-3.10.6) of the _The
Java Language Specification_ for the full list. Developers will have access to escape
processing via `String::translateEscapes`, a new instance method.
Interpreting escapes as the final step allows developers to use `\n`, `\f`, and `\r` for
vertical formatting of a string without it affecting the translation of line terminators in
step 1, and to use `\b` and `\t` for horizontal formatting of a string without it affecting
the removal of incidental white space in step 2. For example, consider this text block that
contains the `\r` escape sequence (CR):
``` String html = """ \r \r
Hello, world
\r \r \r """;
```
The CR escapes are not processed until after the line terminators have been normalized to LF.
Using Unicode escapes to visualize LF (`\u000A`) and CR (`\u000D`), the result is:
``` |\u000D\u000A | \u000D\u000A | Hello, world
\u000D\u000A |
\u000D\u000A |\u000D\u000A ```
Note that it is legal to use `"` and `""` freely inside a text block, except immediately
before the closing delimiter. For example, the following text blocks are legal:
``` String story = """ "When I use a word," Humpty Dumpty said, in rather a scornful
tone, "it means just what I choose it to mean - neither more nor less." "The question
is," said Alice, "whether you can make words mean so many different things." "The
question is," said Humpty Dumpty, "which is to be master - that's all." """; //
Note the newline before the closing delimiter
String code = """ String empty = ""; """; ```
However, a sequence of three `"` characters requires at least one `"` to be escaped, in order
to avoid mimicking the closing delimiter. (A sequence of n `"` characters requires at least
`Math.floorDiv(n,3)` of them to be escaped.) The use of `"` immediately before the closing
delimiter also requires escaping. For example:
``` String code = """ String text = \""" A text block inside a text block
\"""; """;
String tutorial1 = """ A common character in Java programs is \"""";
String tutorial2 = """ The empty string literal is formed from " characters as
follows: \"\"""";
System.out.println(""" 1 " 2 "" 3 ""\" 4 ""\"" 5 ""\""" 6
""\"""\" 7 ""\"""\"" 8 ""\"""\""" 9 ""\"""\"""\" 10 ""\"""\"""\"" 11
""\"""\"""\""" 12 ""\"""\"""\"""\" """); ```
### New escape sequences
To allow finer control of the processing of newlines and white space, we introduce two new
escape sequences.
First, the `\` escape sequence explicitly suppresses the insertion of a
newline character.
For example, it is common practice to split very long string literals into concatenations of
smaller substrings, and then hard wrap the resulting string expression onto multiple lines:
String literal = "Lorem ipsum dolor sit amet, consectetur adipiscing " +
"elit, sed do eiusmod tempor incididunt ut labore " + "et dolore magna
aliqua.";
With the `\` escape sequence this could be expressed as:
String text = """ Lorem ipsum dolor sit amet, consectetur adipiscing \
elit, sed do eiusmod tempor incididunt ut labore \ et dolore magna
aliqua.\ """;
For the simple reason that character literals and traditional string literals don't allow
embedded newlines, the `\` escape sequence is only applicable to text blocks.
Second, the new `\s` escape sequence simply translates to a single space (`\u0020`).
Escape sequences aren't translated until after incidental space stripping, so `\s` can act as
fence to prevent the stripping of trailing white space. Using `\s` at the end of each line in
this example guarantees that each line is exactly six characters long:
String colors = """ red \s green\s blue \s """;
The `\s` escape sequence can be used in text blocks, traditional string literals, and
character literals.
### Concatenation of text blocks
Text blocks can be used anywhere a string literal can be used. For example, text blocks and
string literals may be concatenated interchangeably:
``` String code = "public void print(Object o) {" + """
System.out.println(Objects.toString(o)); } """; ```
However, concatenation involving a text block can become rather clunky. Take this text block
as a starting point:
``` String code = """ public void print(Object o) {
System.out.println(Objects.toString(o)); } """; ```
Suppose it needs to be changed so that the type of `o` comes from a variable. Using
concatenation, the text block that contains the trailing code will need to start on a new
line. Unfortunately, the straightforward insertion of a newline in the program, as below, will
cause a long span of white space between the type and the text beginning `o` :
``` String code = """ public void print(""" + type + """
o) { System.out.println(Objects.toString(o)); }
"""; ```
The white space can be removed manually, but this hurts readability of the quoted code:
``` String code = """ public void print(""" + type + """ o) {
System.out.println(Objects.toString(o)); } """; ```
A cleaner alternative is to use `String::replace` or `String::format`, as follows:
``` String code = """ public void print($type o) {
System.out.println(Objects.toString(o)); } """.replace("$type",
type); ```
``` String code = String.format(""" public void print(%s o) {
System.out.println(Objects.toString(o)); } """, type); ```
Another alternative involves the introduction of a new instance method, `String::formatted`,
which could be used as follows:
``` String source = """ public void print(%s object) {
System.out.println(Objects.toString(object)); }
""".formatted(type); ```
### Additional Methods
The following methods will be added to support text blocks;
- `String::stripIndent()`: used to strip away incidental white space from the text block
content - `String::translateEscapes()`: used to translate escape sequences -
`String::formatted(Object... args)`: simplify value substitution in the text block
Alternatives ------------
### Do nothing
Java has prospered for over 20 years with string literals that required newlines to be
escaped. IDEs ease the maintenance burden by supporting automatic formatting and concatenation
of strings that span several lines of source code. The `String` class has also evolved to
include methods that simplify the processing and formatting of long strings, such as a method
that presents a string as a [stream of
lines](https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/lang/String.html#lines()).
However, strings are such a fundamental part of the Java language that the shortcomings of
string literals are apparent to [vast numbers of
developers](https://stackoverflow.com/questions/878573/java-multiline-string). Other JVM
languages have also made advances in how long and complex strings are denoted. Unsurprisingly,
then, multi-line string literals have consistently been one of the most requested features for
Java. Introducing a multi-line construct of low to moderate complexity would have a high
payoff.
### Allow a string literal to span multiple lines
Multi-line string literals could be introduced in Java simply by allowing line terminators in
existing string literals. However, this would do nothing about the pain of escaping `"`
characters. `\"` is the most frequently occurring escape sequence after `\n`, because of
frequency of code snippets. The only way to avoid escaping `"` in a string literal would be to
provide an alternate delimiter scheme for string literals. Delimiters were much discussed for
[JEP 326](https://openjdk.java.net/jeps/326) (Raw String Literals), and the lessons learned
were used to inform the design of text blocks, so it would be misguided to upset the stability
of string literals.
### Adopt another language's multi-string literal
According to [Brian
Goetz](https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-March/001082.html):
> Many people have suggested that Java should adopt multi-line string literals from Swift or
Rust. However, the approach of “just do what language X does” is intrinsically irresponsible;
nearly every feature of every language is conditioned by other features of that language.
Instead, the game is to learn from how other languages do things, assess the tradeoffs they’ve
chosen (explicitly and implicitly), and ask what can be applied to the constraints of the
language we have and user expectations within the community we have.
For [JEP 326](https://openjdk.java.net/jeps/326) (Raw String Literals), we surveyed many
modern programming languages and their support for multi-line string literals. The results of
these surveys influenced the current proposal, such as the choice of three `"` characters for
delimiters (although there were other reasons for this choice too) and the recognition of the
need for automatic indentation management.
### Do not remove incidental white space
If Java introduced multi-line string literals without support for automatically removing
incidental white space, then many developers would write a method to remove it themselves, or
lobby for the `String` class to include a removal method. However, that implies a potentially
expensive computation every time the string is instantiated at run time, which would reduce
the benefit of string interning. Having the Java language mandate the removal of incidental
white space, both in leading and trailing positions, seems the most appropriate solution.
Developers can opt out of leading white space removal by careful placement of the closing
delimiter.
### Raw string literals
For [JEP 326](https://openjdk.java.net/jeps/326) (Raw String Literals), we took a different
approach to the problem of denoting strings without escaping newlines and quotes, focusing on
the raw-ness of strings. We now believe that this focus was wrong, because while raw string
literals could easily span multiple lines of source code, the cost of supporting unescaped
delimiters in their content was extreme. This limited the effectiveness of the feature in the
multi-line use case, which is a critical one because of the frequency of embedding multi-line
(but not truly raw) code snippets in Java programs. A good outcome of the pivot from raw-ness
to multi-line-ness was a renewed focus on having a consistent escape language between string
literals, text blocks, and related features that may be added in future.
Testing -------
Tests that use string literals for the creation, interning, and manipulation of instances of
`String` should be duplicated to use text blocks too. Negative tests should be added for
corner cases involving line terminators and EOF.
Tests should be added to ensure that text blocks can embed Java-in-Java, Markdown-in-Java,
SQL-in-Java, and at least one JVM-language-in-Java.
JDK-8243579: Support for Unicode 13.0
This release upgrades Unicode support to 13.0, which includes the following: - The
`java.lang.Character` class supports Unicode Character Database of 13.0 level, which 13.0 adds
5,930 characters, for a total of 143,859 characters. These additions include 4 new scripts,
for a total of 154 scripts, as well as 55 new emoji characters. - The `java.text.Bidi` and
`java.text.Normalizer` classes support 13.0 level of Unicode Standard Annexes, #9 and #15,
respectively. - The `java.util.regex` package supports Extended Grapheme Clusters based on
13.0 level of Unicode Standard Annex #29 For more detail about Unicode 13.0, refer to the
[Unicode Consortium's release note](https://unicode.org/versions/Unicode13.0.0/).
core-libs/java.lang.invoke:
JDK-8243093: JEP 371: Hidden Classes
[JEP 371](https://openjdk.java.net/jeps/371) introduces hidden classes in Java 15. Hidden
classes have the following implications to existing code:
1. `Class::getName` traditionally returns a binary name, but for a hidden class it returns a
string that contains an ASCII forward slash (`/`) and is therefore not a binary name. Programs
that assume the returned string is a binary name might need to be updated to handle hidden
classes. That said, the longstanding practice of `Unsafe::defineAnonymousClass` was to define
classes whose names were not binary names, so some programs may already handle such names
successfully.
2. `Class::descriptorString` and `MethodType::descriptorString` returns a string that contains
a ASCII dot (`.`) for a hidden class and therefore is not a type descriptor conforming to
JVMS 4.3. Programs that assume the returned string is a type descriptor that conforms to
JVMS 4.3 might need to be updated to handle hidden classes.
3. `Class::getNestMembers` is changed to not throw an exception when it fails to validate a
nest membership of any member listed in `NestMembers` attribute. Instead,
`Class::getNestMembers` returns the nest host and the members listed in the host's
`NestMembers` attribute that are successfully resolved and determined to have the same nest
host as this class. (This means it may return fewer members that listed in `NestMembers`
attribute.) Existing code that expects `LinkageError` when there is a bad nest membership
might be impacted. 4. The nestmate test in the JVM is changed to throw only
`IllegalAccessError` when the nest membership is invalid. Some historical understanding is
necessary: - In Java 8, every access control failure was signaled with `IllegalAccessError`
(IAE). Moreover, if a given access check failed with IAE once, then the same check would fail
with IAE every time. - In Java 11, the introduction of nest mates (JEP 181) meant that an
access control failure could be signaled either with `IllegalAccessError` or, if nest
membership was invalid, `LinkageError`. Still, if a given access check failed with a specific
exception, then the same check would always fail with the same exception. - In Java 15, the
introduction of `Lookup::defineHiddenClass` implies that the nest host of the lookup class
must be determined eagerly, when the hidden class is defined as a nestmate of the lookup
class. Both `Lookup::defineHiddenClass` and `Class::getNestHost` both determine the nest host
of a class in a more resilient manner than the JVM did in Java 11; namely, the API simply
treats a class as self-hosted if its purported nest membership is invalid. For consistency
with the API, the JVM no longer throws `LinkageError` when a class's nest membership is
invalid, and instead treats the class as self-hosted. This means that the JVM only throws IAE
from access control (because a self-hosted class will not permit any other class to access its
private members). This is the behavior expected by the vast majority of user code.
5. JVM TI `GetClassSignature` returns a string that contains a ASCII dot (`.`) for a hidden
class. JVM TI agents might need updating for hidden classes if they assume the returned
string from `GetClassSignature` is a type descriptor conforming to JVMS 4.3.
JDK-8246791: Lookup::defineClass Links the Class
`Lookup::defineClass` is specified to throw `LinkageError` if a linkage error occurs, but the
implementation was not actually linking the class. In this release, the implementation has
been changed to link the class before returning, so conforming to the specification. If
`Lookup::defineClass` is called to define a class that fails linking, `LinkageError` will be
thrown.
core-libs/java.net:
JDK-8243390: DatagramPacket.getPort() Returns 0 When the Port Is Not Set
In this release, the default port number for a datagram packet has been changed to 0.
Previously, this value was -1, which was undocumented. The port can be retrieved by using
`DatagramPacket::getPort`.
JDK-8247324: DatagramSocket::disconnect Allows an Implementation to Throw UncheckedIOException
Previously, `DatagramChannel::disconnect` threw an `IOException` while
`DatagramSocket::disconnect` did not. As a result, the `DatagramChannel::socket` adapter,
which calls `DatagramChannel::disconnect`, catches the thrown `IOException` and rethrows it as
an `Error`. However, this was undocumented behavior and not user-friendly.
The `DatagramChannel::socket` adapter has been changed to throw an `UncheckedIOException`, and
the specification of `DatagramSocket::disconnect` has been updated to document that an
implementation may now throw an `UncheckedIOException`. This ensures consistency in behavior
between `DatagramSocket`, `DatagramChannel`, and `DatagramChannel::socket` adapter.
JDK-8242387: java.net.HttpClient Does Not Override Protocols Specified in SSLContext Default Parameters
During the setup of new connections, `java.net.http.HttpClient` now uses the default set of
protocols provided by the `SSLContext` when negotiating the TLS handshake. In the absence of
any `SSLParameter`s explicitly supplied to the `HttpClient.builder`, the `HttpClient` has been
updated to no longer override any default-selected protocols in the SSLContext. As a result,
the actual TLS version that is negotiated might differ from that of previous releases, or it
might even succeed or fail to negotiate when it previously might not have.
JDK-8248328: Filtering and Ordering of Addresses Returned by Alternative Hosts File Name Service Provider
In this release, the behavior of `InetAddress.getAllByName` has been modified when the
alternative hosts file name service is selected .
The JDK allows specifying an alternative host's file name service by using the
`jdk.net.hosts.file` system property. The implementation of the alternative name service has
been changed to take into account the values of the `java.net.preferIPv4Stack` and
`java.net.preferIPv6Addresses` system properties. This affects the results returned by
`InetAddress.getAllByName` when the host's file name service is selected. For details about
`java.net.preferIPv4Stack` and `java.net.preferIPv6Addresses`, see [Networking
Properties](https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/net/doc-files/net-properties.html)
in the API documentation.
JDK-8234871: deprecate SocketFlow (SO_FLOW_SLA) and related APIs for removal
The SocketFlow and SO_FLOW_SLA socket options are Solaris-specific and should be deprecated
for removal. See http://openjdk.java.net/jeps/362 (JDK-8231554).
The related NetworkPermissions should also be deprecated for removal.
JDK-8247325: Removal of Terminally Deprecated Solaris-specific SO_FLOW_SLA Socket Option
In this release, in conjunction with the removal of the Solaris port in [JEP
381](https://openjdk.java.net/jeps/381), the JDK-specific socket option
`jdk.net.ExtendedSocketOptions.SO_FLOW_SLA`, which is only relevant to sockets on Solaris, and
its supporting classes `SocketFlow` and `SocketFlow.Status`, have been removed.
JDK-8250845: Added Support for SO_INCOMING_NAPI_ID Support
A new JDK-specific socket option `SO_INCOMING_NAPI_ID` has been added to
`jdk.net.ExtendedSocketOptions` in this release. The socket option is Linux specific and
allows applications to query the NAPI (New API) ID of the underlying device queue associated
with its socket connection and take advantage of the Application Device Queue (ADQ) feature of
high performance Network Interface Card (NIC) devices.
core-libs/java.nio.charsets:
JDK-8240196: Modified the MS950 charset Encoder's Conversion Table
In this release, some of the one-way byte-to-char mappings have been aligned with the
preferred mappings provided by the [Unicode
Consortium](https://unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit950.txt).
core-libs/java.rmi:
JDK-8246021: Deprecated RMI Activation for Removal
The RMI Activation mechanism has been deprecated and may be removed in a future version of the
platform. RMI Activation is an obsolete part of RMI that has been optional since Java 8. It
allows RMI server JVMs to be started ("activated") upon receipt of a request from a client,
instead of requiring RMI server JVMs to be running continuously. Other parts of RMI are not
deprecated. See [JEP 385](http://openjdk.java.net/jeps/385) for further information.
JDK-8242119: Removal of RMI Static Stub Compiler (rmic)
The RMI static stub compiler `rmic` has been removed. The `rmic` tool is obsolete and has been
deprecated for removal since JDK 13.
core-libs/java.text:
JDK-8236687: Support Monetary Grouping Separator in DecimalFormat/DecimalFormatSymbols
DecimalFormat/DecimalFormatSymbols classes are now capable of dealing with grouping separators
for currency values. For example, the monetary grouping separator for the German language used
in Austria (the de-AT locale) is '.', whereas the monetary grouping separator in other German
locales is ' '.
core-libs/java.time:
JDK-8244555: localizedBy() Overrides Localized Values With Default Values
`java.time.format.DateTimeFormatter.localizedBy(Locale)` method now honors the default locale
values, such as `Chronology`and/or `DecimalStyle` of the specified locale argument.
For example, in previous JDK releases: ``` jshell>
DateTimeFormatter.ofLocalizedDate(FormatStyle.FULL)
.localizedBy(Locale.forLanguageTag("fa")) .format(LocalDate.now()) $3 ==> "جمعه 1 مهٔ
2020" ``` the numbers are in Arabic (Western) numerals. In JDK 15: ``` jshell>
DateTimeFormatter.ofLocalizedDate(FormatStyle.FULL)
.localizedBy(Locale.forLanguageTag("fa")) .format(LocalDate.now()) $3 ==> "جمعه ۱ مهٔ
۲۰۲۰" ``` the numbers are in Extended Arabic-Indic numerals because it is the default
numbering system for the Farsi locale.
JDK-8239882: ValueRange.of(long, long, long) Does Not Throw IAE on Invalid Inputs
```java.time.temporal.ValueRange.of()``` methods are now correctly throwing an
InvalidArgumentException on given invalid arguments. For example, ```of(5, 2, 10)``` which is
invalid because the ```minimum``` is greater than the ```smallest maximum```, now throws the
exception.
core-libs/java.util.jar:
JDK-8251360: Performance Improvement for InflaterOutputStream.write
`InflaterOutputStream(OutputStream out, Inflater infl, int bufLen)` allows for specifying the
decompressor and buffer size to be used.
`InflaterOutputStream.write(byte[] b, int off, int len)` was writing data using a max buffer
size of 512 bytes.
Starting with JDK 15 the buffer size specified via `InflaterOutputStream(OutputStream out,
Inflater infl, int bufLen)` will be used in calls to `InflaterOutputStream.write(byte[] b,
int off, int len)`. If the buffer size is not specified when invoking the
`InflaterOutputStream `constructor, it will default to 512 bytes.
core-libs/java.util.regex:
JDK-8239887: Case Insensitive Matching Doesn't Work Correctly for Some Character Classes
The Java regular expression engine supports the case insensitive mode. When this mode is
turned on, the engine is supposed to match the input text without regard to the case of the
characters it consists of.
However, the current implementation of matching against some named character classes (those
that are encoded with \p{name} or \P{name} constructs) fails to respect the case insensitive
mode.
This fix makes these character classes behave consistently with respect to case sensitivity.
When the regular expression engine operates in the case insensitive mode, the named character
classes will match the input characters without regard to their case: lower case, upper case,
or title case.
core-libs/java.util:collections:
JDK-8250842: Specialized Implementations of TreeMap Methods
The TreeMap class now provides overriding implementations of the `putIfAbsent`,
`computeIfAbsent`, `computeIfPresent`, `compute`, and `merge` methods. The new implementations
provide a performance improvement. However, if the function provided to the `compute-` or
`merge` methods modifies the map, ConcurrentModificationException may be thrown, because the
function that is provided to these methods is prohibited from modifying the map. If a
ConcurrentModificationException occurs, the function must either be changed to avoid modifying
the map, or the surrounding code should be rewritten to replace uses of the `compute-` and
`merge` methods with conventional Map methods such as `get` and `put`.
See JDK-8227666 for further information.
core-libs/java.util:i18n:
JDK-8238914: Localized Time Zone Name Inconsistency Between English and Other Locales
English time zone names provided by the CLDR locale provider are now correctly synthesized
following the CLDR spec, rather than substituted from the COMPAT provider. For example, SHORT
style names are no longer synthesized abbreviations of LONG style names, but instead produce
GMT offset formats.
JDK-8243581: Support for CLDR version 37
Locale data based on Unicode Consortium's CLDR has been upgraded to their version 37. For the
detailed locale data changes, please refer to the Unicode Consortium's CLDR release notes: -
[http://cldr.unicode.org/index/downloads/cldr-37](http://cldr.unicode.org/index/downloads/cldr-37)
core-libs/javax.lang.model:
JDK-8236934: JEP 378: Text Blocks
Summary -------
Add _text blocks_ to the Java language. A text block is a multi-line string literal that
avoids the need for most escape sequences, automatically formats the string in a predictable
way, and gives the developer control over the format when desired.
History -------
Text blocks were proposed by [JEP 355](https://openjdk.java.net/jeps/355) in early 2019 as a
follow-on to explorations begun in [JEP 326](https://openjdk.java.net/jeps/326) (Raw String
Literals), which was initially targeted to JDK 12 but eventually [withdrawn and did not appear
in that release](https://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002402.html).
JEP 355 was [targeted to JDK 13 in June
2019](https://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003050.html) as a [preview
feature](http://openjdk.java.net/jeps/12). Feedback on JDK 13 suggested that text blocks
should be previewed again in JDK 14, with the addition of [two new escape
sequences](#New-escape-sequences). Consequently, [JEP 368](https://openjdk.java.net/jeps/368)
was [targeted to JDK 14 in November
2019](https://mail.openjdk.java.net/pipermail/jdk-dev/2019-November/003653.html) as a preview
feature. Feedback on JDK 14 suggested that text blocks were ready to become final and
permanent in JDK 15 with no further changes.
Goals -----
- Simplify the task of writing Java programs by making it easy to express strings that span
several lines of source code, while avoiding escape sequences in common cases.
- Enhance the readability of strings in Java programs that denote code written in non-Java
languages.
- Support migration from string literals by stipulating that any new construct can express the
same set of strings as a string literal, interpret the same escape sequences, and be
manipulated in the same ways as a string literal.
- Add escape sequences for managing explicit white space and newline control.
Non-Goals ---------
- It is not a goal to define a new reference type, distinct from `java.lang.String`, for the
strings expressed by any new construct.
- It is not a goal to define new operators, distinct from `+`, that take `String` operands.
- Text blocks do not directly support string interpolation. Interpolation may be considered in
a future JEP. In the meantime, the new instance method `String::formatted` aids in situations
where interpolation might be desired.
- Text blocks do not support raw strings, that is, strings whose characters are not processed
in any way.
Motivation ----------
In Java, embedding a snippet of HTML, XML, SQL, or JSON in a string literal `"..."` usually
requires significant editing with escapes and concatenation before the code containing the
snippet will compile. The snippet is often difficult to read and arduous to maintain.
More generally, the need to denote short, medium, and long blocks of text in a Java program is
near universal, whether the text is code from other programming languages, structured text
representing golden files, or messages in natural languages. On the one hand, the Java
language recognizes this need by allowing strings of unbounded size and content; on the other
hand, it embodies a design default that strings should be small enough to denote on a single
line of a source file (surrounded by " characters), and simple enough to escape easily. This
design default is at odds with the large number of Java programs where strings are too long to
fit comfortably on a single line.
Accordingly, it would improve both the readability and the writability of a broad class of
Java programs to have a linguistic mechanism for denoting strings more literally than a string
literal -- across multiple lines and without the visual clutter of escapes. In essence, a
two-dimensional block of text, rather than a one-dimensional sequence of characters.
Still, it is impossible to predict the role of every string in Java programs. Just because a
string spans multiple lines of source code does not mean that newline characters are desirable
in the string. One part of a program may be more readable when strings are laid out over
multiple lines, but the embedded newline characters may change the behavior of another part of
the program. Accordingly, it would be helpful if the developer had precise control over where
newlines appear, and, as a related matter, how much white space appears to the left and right
of the "block" of text.
### HTML example
_Using "one-dimensional" string literals_
``` String html = "\n" + " \n" + " Hello,
world
\n" + " \n" + "\n"; ```
_Using a "two-dimensional" block of text_
``` String html = """
Hello, world
"""; ```
### SQL example
_Using "one-dimensional" string literals_
``` String query = "SELECT \"EMP_ID\", \"LAST_NAME\" FROM \"EMPLOYEE_TB\"\n" +
"WHERE \"CITY\" = 'INDIANAPOLIS'\n" + "ORDER BY \"EMP_ID\", \"LAST_NAME\";\n";
```
_Using a "two-dimensional" block of text_
``` String query = """ SELECT "EMP_ID", "LAST_NAME" FROM "EMPLOYEE_TB"
WHERE "CITY" = 'INDIANAPOLIS' ORDER BY "EMP_ID", "LAST_NAME";
"""; ```
### Polyglot language example
_Using "one-dimensional" string literals_
``` ScriptEngine engine = new ScriptEngineManager().getEngineByName("js"); Object obj =
engine.eval("function hello() {\n" + " print('\"Hello,
world\"');\n" + "}\n" + "\n" +
"hello();\n"); ```
_Using a "two-dimensional" block of text_
``` ScriptEngine engine = new ScriptEngineManager().getEngineByName("js"); Object obj =
engine.eval(""" function hello() {
print('"Hello, world"'); }
hello(); """); ```
Description -----------
> _This section is identical to the same section in this JEP's predecessor, [JEP
355](https://openjdk.java.net/jeps/355), except for the addition of the subsection on [new
escape sequences](#New-escape-sequences)._
A _text block_ is a new kind of literal in the Java language. It may be used to denote a
string anywhere that a _[string
literal](https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-3.10.5)_ could
appear, but offers greater expressiveness and less accidental complexity.
A text block consists of zero or more content characters, enclosed by opening and closing
delimiters.
The _opening delimiter_ is a sequence of three double quote characters (`"""`) followed by
zero or more white spaces followed by a line terminator. The _content_ begins at the first
character after the line terminator of the opening delimiter.
The _closing delimiter_ is a sequence of three double quote characters. The content ends at
the last character before the first double quote of the closing delimiter.
The content may include double quote characters directly, unlike the characters in a string
literal. The use of `\"` in a text block is permitted, but not necessary or recommended. Fat
delimiters (`"""`) were chosen so that `"` characters could appear unescaped, and also to
visually distinguish a text block from a string literal.
The content may include line terminators directly, unlike the characters in a string literal.
The use of `\n` in a text block is permitted, but not necessary or recommended. For example,
the text block:
``` """ line 1 line 2 line 3 """ ```
is equivalent to the string literal:
``` "line 1\nline 2\nline 3\n" ```
or a concatenation of string literals:
``` "line 1\n" + "line 2\n" + "line 3\n" ```
If a line terminator is not required at the end of the string, then the closing delimiter can
be placed on the last line of content. For example, the text block:
``` """ line 1 line 2 line 3""" ```
is equivalent to the string literal:
``` "line 1\nline 2\nline 3" ```
A text block can denote the empty string, although this is not recommended because it needs
two lines of source code:
``` String empty = """ """; ```
Here are some examples of ill-formed text blocks:
``` String a = """"""; // no line terminator after opening delimiter String b = """ """; //
no line terminator after opening delimiter String c = """ "; // no closing
delimiter (text block continues to EOF) String d = """ abc \ def """;
// unescaped backslash (see below for escape processing) ```
### Compile-time processing
A text block is a [constant
expression](https://docs.oracle.com/javase/specs/jls/se12/html/jls-15.html#jls-15.28) of type
`String`, just like a string literal. However, unlike a string literal, the content of a text
block is processed by the Java compiler in three distinct steps:
1. Line terminators in the content are translated to LF (`\u000A`). The purpose of this
translation is to follow the principle of least surprise when moving Java source code across
platforms.
2. Incidental white space surrounding the content, introduced to match the indentation of Java
source code, is removed.
3. Escape sequences in the content are interpreted. Performing interpretation as the final
step means developers can write escape sequences such as `\n` without them being modified or
deleted by earlier steps.
The processed content is recorded in the `class` file as a `CONSTANT_String_info` entry in the
constant pool, just like the characters of a string literal. The `class` file does not record
whether a `CONSTANT_String_info` entry was derived from a text block or a string literal.
At run time, a text block is evaluated to an instance of `String`, just like a string literal.
Instances of `String` that are derived from text blocks are indistinguishable from instances
derived from string literals. Two text blocks with the same processed content will refer to
the same instance of `String` due to
[interning](https://docs.oracle.com/javase/specs/jvms/se12/html/jvms-5.html#jvms-5.1-300), just
like for [string
literals](https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-3.10.5-410).
The following sections discuss compile-time processing in more detail.
#### 1. Line terminators
Line terminators in the content are _normalized_ from CR (`\u000D`) and CRLF (`\u000D\u000A`)
to LF (`\u000A`) by the Java compiler. This ensures that the string derived from the content
is equivalent across platforms, even if the source code has been translated to a platform
encoding (see `javac -encoding`).
For example, if Java source code that was created on a Unix platform (where the line
terminator is LF) is edited on a Windows platform (where the line terminator is CRLF), then
without normalization, the content would become one character longer for each line. Any
algorithm that relied on LF being the line terminator might fail, and any test that needed to
verify string equality with `String::equals` would fail.
The escape sequences `\n` (LF), `\f` (FF), and `\r` (CR) are _not_ interpreted during
normalization; escape processing happens later.
#### 2. Incidental white space
The text blocks [shown above](#Motivation) were easier to read than their concatenated string
literal counterparts, but the obvious interpretation for the content of a text block would
include the spaces added to indent the embedded string so that it lines up neatly with the
opening delimiter. Here is the HTML example using dots to visualize the spaces that the
developer added for indentation:
``` String html = """ .............. .............. ..............
Hello, world
.............. .............. .............."""; ```
Since the opening delimiter is generally positioned to appear on the same line as the
statement or expression which consumes the text block, there is no real significance to the
fact that 14 visualized spaces start each line. Including those spaces in the content would
mean the text block denotes a string different from the one denoted by the concatenated string
literals. This would hurt migration, and be a recurring source of surprise: it is
overwhelmingly likely that the developer does _not_ want those spaces in the string. Also, the
closing delimiter is generally positioned to align with the content, which further suggests
that the 14 visualized spaces are insignificant.
Spaces may also appear at the end of each line, especially when a text block is populated by
copy-pasting snippets from other files (which may themselves have been formed by copy-pasting
from yet more files). Here is the HTML example reimagined with some trailing white space,
again using dots to visualize spaces:
``` String html = """ ................. .............. ..............
Hello, world
.... .............. . ................. ..............""";
```
Trailing white space is most often unintentional, idiosyncratic, and insignificant. It is
overwhelmingly likely that the developer does not care about it. Trailing white space
characters are similar to line terminators, in that both are invisible artifacts of the source
code editing environment. With no visual guide to the presence of trailing white space
characters, including them in the content would be a recurring source of surprise, as it would
affect the length, hash code, etc, of the string.
Accordingly, an appropriate interpretation for the content of a text block is to differentiate
_incidental white space_ at the start and end of each line, from _essential white space_. The
Java compiler processes the content by removing incidental white space to yield what the
developer intended. `String::indent` can then be used to further manipulate indentation if
desired. Using `|` to visualize margins:
``` || | | | Hello, world
| | | || ```
The _re-indentation algorithm_ takes the content of a text block whose line terminators have
been normalized to LF. It removes the same amount of white space from each line of content
until at least one of the lines has a non-white space character in the leftmost position. The
position of the opening `"""` characters has no effect on the algorithm, but the position of
the closing `"""` characters does have an effect if placed on its own line. The algorithm is
as follows:
1. Split the content of the text block at every LF, producing a list of _individual lines_.
Note that any line in the content which was just an LF will become an empty line in the list
of individual lines.
2. Add all _non-blank_ lines from the list of individual lines into a set of _determining
lines_. (Blank lines -- lines that are empty or are composed wholly of white space -- have no
visible influence on the indentation. Excluding blank lines from the set of determining lines
avoids throwing off step 4 of the algorithm.)
3. If the last line in the list of individual lines (i.e., the line with the closing
delimiter) is _blank_, then add it to the set of determining lines. (The indentation of the
closing delimiter should influence the indentation of the content as a whole -- a
[_significant trailing line_](#Significant-trailing-line-policy) policy.)
4. Compute the _common white space prefix_ of the set of determining lines, by counting the
number of leading white space characters on each line and taking the minimum count.
5. Remove the common white space prefix from each _non-blank_ line in the list of individual
lines.
6. Remove all trailing white space from all lines in the modified list of individual lines
from step 5. This step collapses wholly-white-space lines in the modified list so that they
are empty, but does not discard them.
7. Construct the result string by joining all the lines in the modified list of individual
lines from step 6, using LF as the separator between lines. If the final line in the list from
step 6 is empty, then the joining LF from the previous line will be the last character in the
result string.
The escape sequences `\b` (backspace), `\t` (tab) and `\s` (space) are _not_ interpreted by
the algorithm; escape processing happens later. Similarly, the `\` escape
sequence does not prevent the splitting of lines on the line-terminator since the sequence is
treated as two separate characters until escape processing.
The re-indentation algorithm will be normative in _The Java Language Specification_.
Developers will have access to it via `String::stripIndent`, a new instance method.
#### Significant trailing line policy
Normally, one would format a text block in two ways: first, position the left edge of the
content to appear under the first `"` of the opening delimiter, and second, place the closing
delimiter on its own line to appear exactly under the opening delimiter. The resulting string
will have no white space at the start of any line, and will not include the trailing blank
line of the closing delimiter.
However, because the trailing blank line is considered a _determining line_, moving it to the
left has the effect of reducing the common white space prefix, and therefore reducing the the
amount of white space that is stripped from the start of every line. In the extreme case,
where the closing delimiter is moved all the way to the left, that reduces the common white
space prefix to zero, effectively opting out of white space stripping.
For example, with the closing delimiter moved all the way to the left, there is no incidental
white space to visualize with dots:
``` String html = """
Hello, world
"""; ```
Including the trailing blank line with the closing delimiter, the common white space prefix is
zero, so zero white space is removed from the start of each line. The algorithm thus produces:
(using `|` to visualize the left margin)
``` | | | Hello, world
| | ```
Alternatively, suppose the closing delimiter is not moved all the way to the left, but rather
under the `t` of `html` so it is eight spaces deeper than the variable declaration:
``` String html = """
Hello, world
"""; ```
The spaces visualized with dots are considered to be incidental:
``` String html = """ ........ ........ ........
Hello, world
........ ........ ........"""; ```
Including the trailing blank line with the closing delimiter, the common white space prefix is
eight, so eight white spaces are removed from the start of each line. The algorithm thus
preserves the essential indentation of the content relative to the closing delimiter:
``` | | | Hello, world
| |
```
Finally, suppose the closing delimiter is moved slightly to the _right_ of the content:
``` String html = """
Hello, world
"""; ```
The spaces visualized with dots are considered to be incidental:
``` String html = """ .............. .............. ..............
Hello, world
.............. .............. .............. """; ```
The common white space prefix is 14, so 14 white spaces are removed from the start of each
line. The trailing blank line is stripped to leave an empty line, which being the last line is
then discarded. In other words, moving the closing delimiter to the right of the content has
no effect, and the algorithm again preserves the essential indentation of the content:
``` | | | Hello, world
| | ```
#### 3. Escape sequences
After the content is re-indented, any _escape sequences_ in the content are interpreted. Text
blocks support all of the escape sequences supported in string literals, including `\n`, `\t`,
`\'`, `\"`, and `\\`. See [section
3.10.6](https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-3.10.6) of the _The
Java Language Specification_ for the full list. Developers will have access to escape
processing via `String::translateEscapes`, a new instance method.
Interpreting escapes as the final step allows developers to use `\n`, `\f`, and `\r` for
vertical formatting of a string without it affecting the translation of line terminators in
step 1, and to use `\b` and `\t` for horizontal formatting of a string without it affecting
the removal of incidental white space in step 2. For example, consider this text block that
contains the `\r` escape sequence (CR):
``` String html = """ \r \r
Hello, world
\r \r \r """;
```
The CR escapes are not processed until after the line terminators have been normalized to LF.
Using Unicode escapes to visualize LF (`\u000A`) and CR (`\u000D`), the result is:
``` |\u000D\u000A | \u000D\u000A | Hello, world
\u000D\u000A |
\u000D\u000A |\u000D\u000A ```
Note that it is legal to use `"` and `""` freely inside a text block, except immediately
before the closing delimiter. For example, the following text blocks are legal:
``` String story = """ "When I use a word," Humpty Dumpty said, in rather a scornful
tone, "it means just what I choose it to mean - neither more nor less." "The question
is," said Alice, "whether you can make words mean so many different things." "The
question is," said Humpty Dumpty, "which is to be master - that's all." """; //
Note the newline before the closing delimiter
String code = """ String empty = ""; """; ```
However, a sequence of three `"` characters requires at least one `"` to be escaped, in order
to avoid mimicking the closing delimiter. (A sequence of n `"` characters requires at least
`Math.floorDiv(n,3)` of them to be escaped.) The use of `"` immediately before the closing
delimiter also requires escaping. For example:
``` String code = """ String text = \""" A text block inside a text block
\"""; """;
String tutorial1 = """ A common character in Java programs is \"""";
String tutorial2 = """ The empty string literal is formed from " characters as
follows: \"\"""";
System.out.println(""" 1 " 2 "" 3 ""\" 4 ""\"" 5 ""\""" 6
""\"""\" 7 ""\"""\"" 8 ""\"""\""" 9 ""\"""\"""\" 10 ""\"""\"""\"" 11
""\"""\"""\""" 12 ""\"""\"""\"""\" """); ```
### New escape sequences
To allow finer control of the processing of newlines and white space, we introduce two new
escape sequences.
First, the `\` escape sequence explicitly suppresses the insertion of a
newline character.
For example, it is common practice to split very long string literals into concatenations of
smaller substrings, and then hard wrap the resulting string expression onto multiple lines:
String literal = "Lorem ipsum dolor sit amet, consectetur adipiscing " +
"elit, sed do eiusmod tempor incididunt ut labore " + "et dolore magna
aliqua.";
With the `\` escape sequence this could be expressed as:
String text = """ Lorem ipsum dolor sit amet, consectetur adipiscing \
elit, sed do eiusmod tempor incididunt ut labore \ et dolore magna
aliqua.\ """;
For the simple reason that character literals and traditional string literals don't allow
embedded newlines, the `\` escape sequence is only applicable to text blocks.
Second, the new `\s` escape sequence simply translates to a single space (`\u0020`).
Escape sequences aren't translated until after incidental space stripping, so `\s` can act as
fence to prevent the stripping of trailing white space. Using `\s` at the end of each line in
this example guarantees that each line is exactly six characters long:
String colors = """ red \s green\s blue \s """;
The `\s` escape sequence can be used in text blocks, traditional string literals, and
character literals.
### Concatenation of text blocks
Text blocks can be used anywhere a string literal can be used. For example, text blocks and
string literals may be concatenated interchangeably:
``` String code = "public void print(Object o) {" + """
System.out.println(Objects.toString(o)); } """; ```
However, concatenation involving a text block can become rather clunky. Take this text block
as a starting point:
``` String code = """ public void print(Object o) {
System.out.println(Objects.toString(o)); } """; ```
Suppose it needs to be changed so that the type of `o` comes from a variable. Using
concatenation, the text block that contains the trailing code will need to start on a new
line. Unfortunately, the straightforward insertion of a newline in the program, as below, will
cause a long span of white space between the type and the text beginning `o` :
``` String code = """ public void print(""" + type + """
o) { System.out.println(Objects.toString(o)); }
"""; ```
The white space can be removed manually, but this hurts readability of the quoted code:
``` String code = """ public void print(""" + type + """ o) {
System.out.println(Objects.toString(o)); } """; ```
A cleaner alternative is to use `String::replace` or `String::format`, as follows:
``` String code = """ public void print($type o) {
System.out.println(Objects.toString(o)); } """.replace("$type",
type); ```
``` String code = String.format(""" public void print(%s o) {
System.out.println(Objects.toString(o)); } """, type); ```
Another alternative involves the introduction of a new instance method, `String::formatted`,
which could be used as follows:
``` String source = """ public void print(%s object) {
System.out.println(Objects.toString(object)); }
""".formatted(type); ```
### Additional Methods
The following methods will be added to support text blocks;
- `String::stripIndent()`: used to strip away incidental white space from the text block
content - `String::translateEscapes()`: used to translate escape sequences -
`String::formatted(Object... args)`: simplify value substitution in the text block
Alternatives ------------
### Do nothing
Java has prospered for over 20 years with string literals that required newlines to be
escaped. IDEs ease the maintenance burden by supporting automatic formatting and concatenation
of strings that span several lines of source code. The `String` class has also evolved to
include methods that simplify the processing and formatting of long strings, such as a method
that presents a string as a [stream of
lines](https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/lang/String.html#lines()).
However, strings are such a fundamental part of the Java language that the shortcomings of
string literals are apparent to [vast numbers of
developers](https://stackoverflow.com/questions/878573/java-multiline-string). Other JVM
languages have also made advances in how long and complex strings are denoted. Unsurprisingly,
then, multi-line string literals have consistently been one of the most requested features for
Java. Introducing a multi-line construct of low to moderate complexity would have a high
payoff.
### Allow a string literal to span multiple lines
Multi-line string literals could be introduced in Java simply by allowing line terminators in
existing string literals. However, this would do nothing about the pain of escaping `"`
characters. `\"` is the most frequently occurring escape sequence after `\n`, because of
frequency of code snippets. The only way to avoid escaping `"` in a string literal would be to
provide an alternate delimiter scheme for string literals. Delimiters were much discussed for
[JEP 326](https://openjdk.java.net/jeps/326) (Raw String Literals), and the lessons learned
were used to inform the design of text blocks, so it would be misguided to upset the stability
of string literals.
### Adopt another language's multi-string literal
According to [Brian
Goetz](https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-March/001082.html):
> Many people have suggested that Java should adopt multi-line string literals from Swift or
Rust. However, the approach of “just do what language X does” is intrinsically irresponsible;
nearly every feature of every language is conditioned by other features of that language.
Instead, the game is to learn from how other languages do things, assess the tradeoffs they’ve
chosen (explicitly and implicitly), and ask what can be applied to the constraints of the
language we have and user expectations within the community we have.
For [JEP 326](https://openjdk.java.net/jeps/326) (Raw String Literals), we surveyed many
modern programming languages and their support for multi-line string literals. The results of
these surveys influenced the current proposal, such as the choice of three `"` characters for
delimiters (although there were other reasons for this choice too) and the recognition of the
need for automatic indentation management.
### Do not remove incidental white space
If Java introduced multi-line string literals without support for automatically removing
incidental white space, then many developers would write a method to remove it themselves, or
lobby for the `String` class to include a removal method. However, that implies a potentially
expensive computation every time the string is instantiated at run time, which would reduce
the benefit of string interning. Having the Java language mandate the removal of incidental
white space, both in leading and trailing positions, seems the most appropriate solution.
Developers can opt out of leading white space removal by careful placement of the closing
delimiter.
### Raw string literals
For [JEP 326](https://openjdk.java.net/jeps/326) (Raw String Literals), we took a different
approach to the problem of denoting strings without escaping newlines and quotes, focusing on
the raw-ness of strings. We now believe that this focus was wrong, because while raw string
literals could easily span multiple lines of source code, the cost of supporting unescaped
delimiters in their content was extreme. This limited the effectiveness of the feature in the
multi-line use case, which is a critical one because of the frequency of embedding multi-line
(but not truly raw) code snippets in Java programs. A good outcome of the pivot from raw-ness
to multi-line-ness was a renewed focus on having a consistent escape language between string
literals, text blocks, and related features that may be added in future.
Testing -------
Tests that use string literals for the creation, interning, and manipulation of instances of
`String` should be duplicated to use text blocks too. Negative tests should be added for
corner cases involving line terminators and EOF.
Tests should be added to ensure that text blocks can embed Java-in-Java, Markdown-in-Java,
SQL-in-Java, and at least one JVM-language-in-Java.
core-libs/jdk.nashorn:
JDK-8236933: JEP 372: Remove the Nashorn JavaScript Engine
Summary -------
Remove the Nashorn JavaScript script engine and APIs, and the `jjs` tool. The engine, the
APIs, and the tool were [deprecated for removal in Java 11](http://openjdk.java.net/jeps/335)
with the express intent to remove them in a future release.
Motivation ----------
The Nashorn JavaScript engine was first incorporated into JDK 8 via [JEP
174](http://openjdk.java.net/jeps/174) as a replacement for the Rhino scripting engine. When
it was released, it was a complete implementation of the ECMAScript-262 5.1 standard.
With the rapid pace at which ECMAScript language constructs, along with APIs, are adapted and
modified, we have found Nashorn challenging to maintain.
Non-Goals ---------
This removal does not affect, in any way, the `javax.script` API.
Description -----------
Two [JDK modules](http://openjdk.java.net/jeps/200#Design-principles) will be permanently
removed:
- `jdk.scripting.nashorn` -- contains the `jdk.nashorn.api.scripting` and
`jdk.nashorn.api.tree` packages.
- `jdk.scripting.nashorn.shell` -- contains the `jjs` tool.
Risks and Assumptions ---------------------
We assume that developers who rely on Nashorn have had enough notice of its proposed removal
to make alternative arrangements. The deprecation-for-removal of Nashorn in JDK 11 was
confirmed in June 2018, causing the proposed removal to be flagged at every use of the
`jdk.nashorn.*` API and the `jjs` tool in JDK 11, 12, and 13. During this period, no set of
credible developers expressed a clear desire to maintain Nashorn in JDK 14 and beyond.
JDK-8236933: JEP 372: Remove the Nashorn JavaScript Engine
Summary -------
Remove the Nashorn JavaScript script engine and APIs, and the `jjs` tool. The engine, the
APIs, and the tool were [deprecated for removal in Java 11](http://openjdk.java.net/jeps/335)
with the express intent to remove them in a future release.
Motivation ----------
The Nashorn JavaScript engine was first incorporated into JDK 8 via [JEP
174](http://openjdk.java.net/jeps/174) as a replacement for the Rhino scripting engine. When
it was released, it was a complete implementation of the ECMAScript-262 5.1 standard.
With the rapid pace at which ECMAScript language constructs, along with APIs, are adapted and
modified, we have found Nashorn challenging to maintain.
Non-Goals ---------
This removal does not affect, in any way, the `javax.script` API.
Description -----------
Two [JDK modules](http://openjdk.java.net/jeps/200#Design-principles) will be permanently
removed:
- `jdk.scripting.nashorn` -- contains the `jdk.nashorn.api.scripting` and
`jdk.nashorn.api.tree` packages.
- `jdk.scripting.nashorn.shell` -- contains the `jjs` tool.
Risks and Assumptions ---------------------
We assume that developers who rely on Nashorn have had enough notice of its proposed removal
to make alternative arrangements. The deprecation-for-removal of Nashorn in JDK 11 was
confirmed in June 2018, causing the proposed removal to be flagged at every use of the
`jdk.nashorn.*` API and the `jjs` tool in JDK 11, 12, and 13. During this period, no set of
credible developers expressed a clear desire to maintain Nashorn in JDK 14 and beyond.
core-svc/javax.management:
JDK-8248353: Added Ability to Configure Third Port for Remote JMX
JMX supports (explicit) remote network access through the configuration of two network ports
(either from the command line or in a property file), by setting the following properties:
`com.sun.management.jmxremote.port=` `com.sun.management.jmxremote.rmi.port=`
Note: If it is not specified, the second port will default to the first.
A third local port is also opened to accept (local) JMX connections. This port previously had
its number selected at random, which could cause port collisions.
However, it is now possible to configure the third JMX port (local only) by using:
`com.sun.management.jmxremote.local.port=`
JDK-8236955: Removal of Deprecated Constant RMIConnectorServer.CREDENTIAL_TYPES
The terminally deprecated constant
`javax.management.remote.rmi.RMIConnectorServer.CREDENTIAL_TYPE` has been removed. A filter
pattern can be specified instead by using `RMIConnectorServer.CREDENTIALS_FILTER_PATTERN`.
core-svc/tools:
JDK-8250551: New Option Added to jstatd for Specifying RMI Connector Port Number
A new `-r ` option has been added to the `jstatd` command to specify the RMI connector
port number. If a port number is not specified, a random available port is used.
JDK-8250554: New Option Added to jcmd for Writing a gzipped Heap Dump
A new integer option `gz` has been added to the `GC.heap_dump` diagnostic command. If it is
specified, it will enable the gzip compression of the written heap dump. The supplied value is
the compression level. It can range from 1 (fastest) to 9 (slowest, but best compression). The
recommended level is 1.
java.lang.RuntimeException: java.net.UnknownHostException: bugs.openjdk.java.net: Temporary failure in name resolution
at com.atlassian.httpclient.apache.httpcomponents.ApacheAsyncHttpClient.lambda$doExecute$4(ApacheAsyncHttpClient.java:345)
at io.atlassian.util.concurrent.Promises.lambda$biFunction$7(Promises.java:424)
at java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at com.atlassian.httpclient.apache.httpcomponents.SettableFuturePromiseHttpPromiseAsyncClient$1.lambda$doFailed$1(SettableFuturePromiseHttpPromiseAsyncClient.java:42)
at com.atlassian.httpclient.apache.httpcomponents.SettableFuturePromiseHttpPromiseAsyncClient.runInContext(SettableFuturePromiseHttpPromiseAsyncClient.java:61)
at com.atlassian.httpclient.apache.httpcomponents.SettableFuturePromiseHttpPromiseAsyncClient$ThreadLocalDelegateRunnable.run(SettableFuturePromiseHttpPromiseAsyncClient.java:129)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.net.UnknownHostException: bugs.openjdk.java.net: Temporary failure in name resolution
at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
at java.base/java.net.InetAddress$PlatformNameService.lookupAllHostAddr(InetAddress.java:929)
at java.base/java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1515)
at java.base/java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:848)
at java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1505)
at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1364)
at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1298)
at org.apache.http.impl.conn.SystemDefaultDnsResolver.resolve(SystemDefaultDnsResolver.java:45)
at com.atlassian.httpclient.apache.httpcomponents.DefaultHostResolver.resolve(DefaultHostResolver.java:15)
at org.apache.http.impl.nio.conn.PoolingNHttpClientConnectionManager$InternalAddressResolver.resolveRemoteAddress(PoolingNHttpClientConnectionManager.java:664)
at org.apache.http.impl.nio.conn.PoolingNHttpClientConnectionManager$InternalAddressResolver.resolveRemoteAddress(PoolingNHttpClientConnectionManager.java:635)
at org.apache.http.nio.pool.AbstractNIOConnPool.processPendingRequest(AbstractNIOConnPool.java:474)
at org.apache.http.nio.pool.AbstractNIOConnPool.lease(AbstractNIOConnPool.java:280)
at org.apache.http.impl.nio.conn.PoolingNHttpClientConnectionManager.requestConnection(PoolingNHttpClientConnectionManager.java:295)
at org.apache.http.impl.nio.client.AbstractClientExchangeHandler.requestConnection(AbstractClientExchangeHandler.java:377)
at org.apache.http.impl.nio.client.DefaultClientExchangeHandlerImpl.start(DefaultClientExchangeHandlerImpl.java:129)
at org.apache.http.impl.nio.client.InternalHttpAsyncClient.execute(InternalHttpAsyncClient.java:141)
at com.atlassian.httpclient.apache.httpcomponents.BoundedHttpAsyncClient.execute(BoundedHttpAsyncClient.java:49)
at org.apache.http.impl.client.cache.CachingHttpAsyncClient.callBackend(CachingHttpAsyncClient.java:691)
at org.apache.http.impl.client.cache.CachingHttpAsyncClient.handleCacheMiss(CachingHttpAsyncClient.java:435)
at org.apache.http.impl.client.cache.CachingHttpAsyncClient.execute(CachingHttpAsyncClient.java:330)
at org.apache.http.impl.client.cache.CachingHttpAsyncClient.execute(CachingHttpAsyncClient.java:281)
at com.atlassian.httpclient.apache.httpcomponents.SettableFuturePromiseHttpPromiseAsyncClient.execute(SettableFuturePromiseHttpPromiseAsyncClient.java:34)
at com.atlassian.httpclient.apache.httpcomponents.ApacheAsyncHttpClient.doExecute(ApacheAsyncHttpClient.java:339)
at com.atlassian.httpclient.apache.httpcomponents.ApacheAsyncHttpClient.execute(ApacheAsyncHttpClient.java:292)
at com.atlassian.httpclient.apache.httpcomponents.DefaultRequest$DefaultRequestBuilder.execute(DefaultRequest.java:258)
at com.atlassian.jira.rest.client.internal.async.AtlassianHttpClientDecorator$AuthenticatedRequestBuilder.execute(AtlassianHttpClientDecorator.java:83)
at com.atlassian.httpclient.apache.httpcomponents.DefaultRequest$DefaultRequestBuilder.get(DefaultRequest.java:221)
at com.atlassian.jira.rest.client.internal.async.AbstractAsynchronousRestClient.getAndParse(AbstractAsynchronousRestClient.java:69)
at com.atlassian.jira.rest.client.internal.async.AsynchronousIssueRestClient.getIssue(AsynchronousIssueRestClient.java:211)
at com.atlassian.jira.rest.client.internal.async.AsynchronousIssueRestClient.getIssue(AsynchronousIssueRestClient.java:202)
at org.openjdk.backports.jira.RetryableIssuePromise.get(RetryableIssuePromise.java:57)
at org.openjdk.backports.jira.RetryableIssuePromise.claimDo(RetryableIssuePromise.java:79)
at org.openjdk.backports.jira.RetryableIssuePromise.claim(RetryableIssuePromise.java:62)
at org.openjdk.backports.jira.Accessors.getReleaseNotes(Accessors.java:229)
at org.openjdk.backports.report.ReleaseNotesReport.run(ReleaseNotesReport.java:162)
at org.openjdk.backports.Main.main(Main.java:83)