RELEASE NOTES FOR: 14
====================================================================================================
Notes generated: Wed Sep 01 04:13:36 CEST 2021
Hint: Prefix bug IDs with https://bugs.openjdk.java.net/browse/ to reach the relevant JIRA entry.
JAVA ENHANCEMENT PROPOSALS (JEP):
JEP 305: Pattern Matching for instanceof (Preview)
Enhance the Java programming language with _pattern matching_ for the `instanceof` operator.
[Pattern matching](http://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](http://openjdk.java.net/jeps/12) in
JDK 14.
JEP 343: Packaging Tool (Incubator)
Create a tool for packaging self-contained Java applications.
JEP 345: NUMA-Aware Memory Allocation for G1
Improve G1 performance on large machines by implementing NUMA-aware memory allocation.
JEP 349: JFR Event Streaming
Expose JDK Flight Recorder data for continuous monitoring.
JEP 352: Non-Volatile Mapped Byte Buffers
Add new JDK-specific file mapping modes so that the `FileChannel` API can be used to create
`MappedByteBuffer` instances that refer to non-volatile memory.
JEP 358: Helpful NullPointerExceptions
Improve the usability of `NullPointerException`s generated by the JVM by describing precisely which
variable was `null`.
JEP 359: Records (Preview)
Enhance the Java programming language with [records][records]. Records provide a compact syntax for
declaring classes which are transparent holders for shallowly immutable data. This is a [preview
language feature](http://openjdk.java.net/jeps/12) in JDK 14.
JEP 361: Switch Expressions
Extend `switch` so it can be used as either a statement or an expression, and so that both forms can
use either traditional `case ... :` labels (with fall through) or new `case ... ->` labels (with no
fall through), with a further new statement for yielding a value from a `switch` expression. These
changes will simplify everyday coding, and prepare the way for the use of pattern matching in
`switch`. This was a [preview language feature](http://openjdk.java.net/jeps/12) in [JDK
12](https://openjdk.java.net/jeps/325) and [JDK 13](https://openjdk.java.net/jeps/354).
JEP 362: Deprecate the Solaris and SPARC Ports
Deprecate the Solaris/SPARC, Solaris/x64, and Linux/SPARC ports, with the intent to remove them in a
future release.
JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector
Remove the Concurrent Mark Sweep (CMS) garbage collector.
JEP 364: ZGC on macOS (Experimental)
Port the ZGC garbage collector to macOS.
JEP 365: ZGC on Windows (Experimental)
Port the ZGC garbage collector to Windows.
JEP 366: Deprecate the ParallelScavenge + SerialOld GC Combination
Deprecate the combination of the Parallel Scavenge and Serial Old garbage collection algorithms.
JEP 367: Remove the Pack200 Tools and API
Remove the `pack200` and `unpack200` tools, and the `Pack200` API in the `java.util.jar` package.
These tools and API were [deprecated for removal in Java SE 11](http://openjdk.java.net/jeps/336)
with the express intent to remove them in a future release.
JEP 368: Text Blocks (Second Preview)
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. This is a [preview language
feature](http://openjdk.java.net/jeps/12) in JDK 14.
JEP 370: Foreign-Memory Access API (Incubator)
Introduce an API to allow Java programs to safely and efficiently access foreign memory outside of
the Java heap.
RELEASE NOTES, BY COMPONENT:
:
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.
xml/javax.xml.transform:
JDK-8229389: Default ErrorListener No Longer Reports Warnings and Errors to the Console
Prior to this release, the `javax.xml.transform.ErrorListener` specification defined that the
default `ErrorListener` implementation reported warnings and errors to `System.err`, and
`System.out` in some cases. This requirement has been removed as of this release and the
default `ErrorListener` now takes no action for warnings and recoverable errors; and in the
case of a severe error, throws a `TransformerException`.
It is recommended that applications always register their own `ErrorListener` to ensure proper
handling of warnings and errors.
tools/javac:
JDK-8235684: Allow Discoverable javac Plugins to be Invoked by Default
javac "plugins" can now opt-in to be started by default if not started explicitly in the
options passed to `javac` from the command-line or in the `options` argument of an API
invocation. This behavior is enabled by implementing the method `Plugin.isDefault()` to
return `true`.
JDK-8238892: toString() on Annotation Objects is Consistent Between Core Reflection and javac
Both core reflection and `javac`, through annotation processing, have objects representing
annotations. The `toString` output for the two kinds of annotation objects now follow the same
conventions. These conventions allow the output to be used in source code.
JDK-8235684: Allow Discoverable javac Plugins to be Invoked by Default
javac "plugins" can now opt-in to be started by default if not started explicitly in the
options passed to `javac` from the command-line or in the `options` argument of an API
invocation. This behavior is enabled by implementing the method `Plugin.isDefault()` to
return `true`.
JDK-8238892: toString() on Annotation Objects is Consistent Between Core Reflection and javac
Both core reflection and `javac`, through annotation processing, have objects representing
annotations. The `toString` output for the two kinds of annotation objects now follow the same
conventions. These conventions allow the output to be used in source code.
deploy:
JDK-8226774: Removal of netscape.javascript.JSObject::getWindow Method
The obsolete `netscape.javascript.JSObject::getWindow` method has been removed. This method
was deprecated in JDK 9. As of JDK 11, there is no longer a useful way to use this method; it
always returns `null`.
core-libs/java.net:
JDK-8234643: Behavior of MulticastSocket getOption/setOption for IP_MULTICAST_LOOP Conforms With the StandardSocketOptions.IP_MULTICAST_LOOP Specification
The `MulticastSocket` methods `getOption` and `setOption` have been changed to conform to the
behavior described in the `StandardSocketOptions.IP_MULTICAST_LOOP` specification.
`MulticastSocket.getOption(StandardSocketOptions.IP_MULTICAST_LOOP)` now returns true if
loopback mode is enabled. Setting
`MulticastSocket.setOption(StandardSocketOptions.IP_MULTICAST_LOOP, true)` enables loopback
mode.
JDK-8232369: InetSocketAddress.toString Format Changes for IPv6 Literals and Unresolved Addresses
The method `InetSocketAddress::toString` has been improved regarding the handling of IPv6
addresses. The implementation now encloses the IPv6 literal in brackets, which adheres to the
specification outlined in RFC2732.
Additionally, the string format for unresolved addresses has been changed. The method now
represents the literal IP address with the token ``, for example:
`foo/:80` instead of `foo:80`. This is based on `InetAddress::toString`, which
returns a string of the form "hostname / literal IP address". To retrieve a string
representation of the hostname, or the string form of the address if it doesn't have a
hostname, use `InetSocketAddress::getHostString`, rather than parsing the string
representation.
JDK-8234266: DatagramSocket.send and MulticastSocket.send Throw IllegalArgumentException When Socket Is Not Connected and Packet Doesn't Contain Address
The `send` methods defined by `DatagramSocket` and `MulticastSocket` have been changed to
throw an `IllegalArgumentException` if the socket is not connected and the `DatagramPacket`
doesn't have a socket address. Prior to this change, these methods threw a
`NullPointerException`.
JDK-8234915: MulticastSocket getOption(IP_MULTICAST_IF) Returns null when outgoing interface not set
The `MulticastSocket` method `getOption` has been changed to conform to the behavior described
in `StandardSocketOptions.IP_MULTICAST_IF`.
`MulticastSocket.getOption(StandardSocketOptions.IP_MULTICAST_IF)` now returns `null` if no
interface has been set.
JDK-8234643: Behavior of MulticastSocket getOption/setOption for IP_MULTICAST_LOOP Conforms With the StandardSocketOptions.IP_MULTICAST_LOOP Specification
The `MulticastSocket` methods `getOption` and `setOption` have been changed to conform to the
behavior described in the `StandardSocketOptions.IP_MULTICAST_LOOP` specification.
`MulticastSocket.getOption(StandardSocketOptions.IP_MULTICAST_LOOP)` now returns true if
loopback mode is enabled. Setting
`MulticastSocket.setOption(StandardSocketOptions.IP_MULTICAST_LOOP, true)` enables loopback
mode.
JDK-8232369: InetSocketAddress.toString Format Changes for IPv6 Literals and Unresolved Addresses
The method `InetSocketAddress::toString` has been improved regarding the handling of IPv6
addresses. The implementation now encloses the IPv6 literal in brackets, which adheres to the
specification outlined in RFC2732.
Additionally, the string format for unresolved addresses has been changed. The method now
represents the literal IP address with the token ``, for example:
`foo/:80` instead of `foo:80`. This is based on `InetAddress::toString`, which
returns a string of the form "hostname / literal IP address". To retrieve a string
representation of the hostname, or the string form of the address if it doesn't have a
hostname, use `InetSocketAddress::getHostString`, rather than parsing the string
representation.
JDK-8234266: DatagramSocket.send and MulticastSocket.send Throw IllegalArgumentException When Socket Is Not Connected and Packet Doesn't Contain Address
The `send` methods defined by `DatagramSocket` and `MulticastSocket` have been changed to
throw an `IllegalArgumentException` if the socket is not connected and the `DatagramPacket`
doesn't have a socket address. Prior to this change, these methods threw a
`NullPointerException`.
JDK-8234915: MulticastSocket getOption(IP_MULTICAST_IF) Returns null when outgoing interface not set
The `MulticastSocket` method `getOption` has been changed to conform to the behavior described
in `StandardSocketOptions.IP_MULTICAST_IF`.
`MulticastSocket.getOption(StandardSocketOptions.IP_MULTICAST_IF)` now returns `null` if no
interface has been set.
JDK-8234643: Behavior of MulticastSocket getOption/setOption for IP_MULTICAST_LOOP Conforms With the StandardSocketOptions.IP_MULTICAST_LOOP Specification
The `MulticastSocket` methods `getOption` and `setOption` have been changed to conform to the
behavior described in the `StandardSocketOptions.IP_MULTICAST_LOOP` specification.
`MulticastSocket.getOption(StandardSocketOptions.IP_MULTICAST_LOOP)` now returns true if
loopback mode is enabled. Setting
`MulticastSocket.setOption(StandardSocketOptions.IP_MULTICAST_LOOP, true)` enables loopback
mode.
JDK-8232369: InetSocketAddress.toString Format Changes for IPv6 Literals and Unresolved Addresses
The method `InetSocketAddress::toString` has been improved regarding the handling of IPv6
addresses. The implementation now encloses the IPv6 literal in brackets, which adheres to the
specification outlined in RFC2732.
Additionally, the string format for unresolved addresses has been changed. The method now
represents the literal IP address with the token ``, for example:
`foo/:80` instead of `foo:80`. This is based on `InetAddress::toString`, which
returns a string of the form "hostname / literal IP address". To retrieve a string
representation of the hostname, or the string form of the address if it doesn't have a
hostname, use `InetSocketAddress::getHostString`, rather than parsing the string
representation.
JDK-8234266: DatagramSocket.send and MulticastSocket.send Throw IllegalArgumentException When Socket Is Not Connected and Packet Doesn't Contain Address
The `send` methods defined by `DatagramSocket` and `MulticastSocket` have been changed to
throw an `IllegalArgumentException` if the socket is not connected and the `DatagramPacket`
doesn't have a socket address. Prior to this change, these methods threw a
`NullPointerException`.
JDK-8234915: MulticastSocket getOption(IP_MULTICAST_IF) Returns null when outgoing interface not set
The `MulticastSocket` method `getOption` has been changed to conform to the behavior described
in `StandardSocketOptions.IP_MULTICAST_IF`.
`MulticastSocket.getOption(StandardSocketOptions.IP_MULTICAST_IF)` now returns `null` if no
interface has been set.
JDK-8234643: Behavior of MulticastSocket getOption/setOption for IP_MULTICAST_LOOP Conforms With the StandardSocketOptions.IP_MULTICAST_LOOP Specification
The `MulticastSocket` methods `getOption` and `setOption` have been changed to conform to the
behavior described in the `StandardSocketOptions.IP_MULTICAST_LOOP` specification.
`MulticastSocket.getOption(StandardSocketOptions.IP_MULTICAST_LOOP)` now returns true if
loopback mode is enabled. Setting
`MulticastSocket.setOption(StandardSocketOptions.IP_MULTICAST_LOOP, true)` enables loopback
mode.
JDK-8232369: InetSocketAddress.toString Format Changes for IPv6 Literals and Unresolved Addresses
The method `InetSocketAddress::toString` has been improved regarding the handling of IPv6
addresses. The implementation now encloses the IPv6 literal in brackets, which adheres to the
specification outlined in RFC2732.
Additionally, the string format for unresolved addresses has been changed. The method now
represents the literal IP address with the token ``, for example:
`foo/:80` instead of `foo:80`. This is based on `InetAddress::toString`, which
returns a string of the form "hostname / literal IP address". To retrieve a string
representation of the hostname, or the string form of the address if it doesn't have a
hostname, use `InetSocketAddress::getHostString`, rather than parsing the string
representation.
JDK-8234266: DatagramSocket.send and MulticastSocket.send Throw IllegalArgumentException When Socket Is Not Connected and Packet Doesn't Contain Address
The `send` methods defined by `DatagramSocket` and `MulticastSocket` have been changed to
throw an `IllegalArgumentException` if the socket is not connected and the `DatagramPacket`
doesn't have a socket address. Prior to this change, these methods threw a
`NullPointerException`.
JDK-8234915: MulticastSocket getOption(IP_MULTICAST_IF) Returns null when outgoing interface not set
The `MulticastSocket` method `getOption` has been changed to conform to the behavior described
in `StandardSocketOptions.IP_MULTICAST_IF`.
`MulticastSocket.getOption(StandardSocketOptions.IP_MULTICAST_IF)` now returns `null` if no
interface has been set.
security-libs/javax.security:
JDK-8233043: DelegationPermission Allows Creating an Instance That Thows NPE on ::equals Call
When a `DelegationPermission` object is created and the `principals` argument does not contain
a pair of principals, an `IllegalArgumentException` is now thrown.
tools/javap:
JDK-8225811: javap Checksum Uses SHA-256
javap includes a checksum of the contents of the class file in verbose output. The checksum is
now calculated with the SHA-256 algorithm, instead of the older MD5 algorithm.
core-libs/java.util:i18n:
JDK-8235444: Plural Support in CompactNumberFormat
```java.text.CompactNumberFormat``` is now capable of dealing with plural forms. For example,
the number ```2,000,000``` is formatted to ```"2 Millionen"``` in ```LONG``` style, whereas
```1,000,000``` to ```"1 Million"``` in the German language.
JDK-8233128: Upgraded CLDR to v36
Locale data based on Unicode Consortium's CLDR has been upgraded to their version 36. For the
detailed locale data changes, please refer to the Unicode Consortium's CLDR release notes: -
[http://cldr.unicode.org/index/downloads/cldr-36](http://cldr.unicode.org/index/downloads/cldr-36)
JDK-8235444: Plural Support in CompactNumberFormat
```java.text.CompactNumberFormat``` is now capable of dealing with plural forms. For example,
the number ```2,000,000``` is formatted to ```"2 Millionen"``` in ```LONG``` style, whereas
```1,000,000``` to ```"1 Million"``` in the German language.
JDK-8233128: Upgraded CLDR to v36
Locale data based on Unicode Consortium's CLDR has been upgraded to their version 36. For the
detailed locale data changes, please refer to the Unicode Consortium's CLDR release notes: -
[http://cldr.unicode.org/index/downloads/cldr-36](http://cldr.unicode.org/index/downloads/cldr-36)
core-libs/java.lang:
JDK-8233196: Thread.countStackFrames Changed to Unconditionally Throw UnsupportedOperationException
The terminally deprecated method `Thread.countStackFrames` has been changed in this release to
unconditionally throw `UnsupportedOperationException`.
This method will be removed in a future release.
JDK-8233042: Thread Suspend/Resume Are Deprecated for Removal
The following methods related to thread suspension in `java.lang.Thread` and
`java.lang.ThreadGroup` have been terminally deprecated in this release:
- `Thread.suspend()` - `Thread.resume()` - `ThreadGroup.suspend()` - `ThreadGroup.resume()` -
`ThreadGroup.allowThreadSuspension(boolean)`
These methods will be removed in a future release.
JDK-8233196: Thread.countStackFrames Changed to Unconditionally Throw UnsupportedOperationException
The terminally deprecated method `Thread.countStackFrames` has been changed in this release to
unconditionally throw `UnsupportedOperationException`.
This method will be removed in a future release.
JDK-8233042: Thread Suspend/Resume Are Deprecated for Removal
The following methods related to thread suspension in `java.lang.Thread` and
`java.lang.ThreadGroup` have been terminally deprecated in this release:
- `Thread.suspend()` - `Thread.resume()` - `ThreadGroup.suspend()` - `ThreadGroup.resume()` -
`ThreadGroup.allowThreadSuspension(boolean)`
These methods will be removed in a future release.
client-libs/2d:
JDK-8230367: Windows 2019 Core Server Is Not Supported
Windows Core Server 2019 does not ship a `dll` required by JDK in order to run. Specifically,
if a Java application, including a headless one, requires `awt.dll`, the Java runtime will
exit with an exception. There is no workaround. Until this is resolved, this Windows Server
configuration is not supported.
specification/language:
JDK-8246771: JEP 395: Records
Summary --------
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_.
[records]: http://cr.openjdk.java.net/~briangoetz/amber/datum.html
History --------
Records were proposed by [JEP 359](https://openjdk.java.net/jeps/359) and delivered in [JDK
14](https://openjdk.java.net/projects/jdk/14) as a [preview
feature](http://openjdk.java.net/jeps/12).
In response to feedback, the design was refined by [JEP
384](https://openjdk.java.net/jeps/384) and delivered in [JDK
15](https://openjdk.java.net/projects/jdk/15) as a preview feature for a second time. The
refinements for the second preview were as follows:
- In the first preview, canonical constructors were required to be `public`. In the second
preview, if the canonical constructor is implicitly declared then its access modifier is the
same as the record class; if the canonical constructor is explicitly declared then its access
modifier must provide at least as much access as the record class.
- The meaning of the `@Override` annotation was extended to include the case where the
annotated method is an explicitly declared accessor method for a record component.
- To enforce the intended use of compact constructors, it became a compile-time error to
assign to any of the instance fields in the constructor body.
- The ability to declare local record classes, local enum classes, and local interfaces was
introduced.
This JEP proposes to finalize the feature in JDK 16, with the following refinement:
- Relax the longstanding restriction whereby an inner class cannot declare a member that is
explicitly or implicitly static. This will become legal and, in particular, will allow an
inner class to declare a member that is a record class.
Additional refinements may be incorporated based on further feedback.
Goals --------
- Devise an object-oriented construct that expresses a simple aggregation of values.
- Help developers to focus on modeling immutable data rather than extensible behavior.
- Automatically implement data-driven methods such as `equals` and accessors.
- Preserve long-standing Java principles such as nominal typing and migration compatibility.
Non-Goals --------
- While records do offer improved concision when declaring data carrier classes, it is not a
goal to declare a "war on boilerplate". In particular, it is not a goal to address the
problems of mutable classes which use the JavaBeans naming conventions.
- It is not a goal to add features such as properties or annotation-driven code generation,
which are often proposed to streamline the declaration of classes for "Plain Old Java
Objects".
Motivation --------
It is a common complaint that "Java is too verbose" or has "too much ceremony". Some of the
worst offenders are classes that are nothing more than immutable _data carriers_ for a handful
of values. Properly writing such a data-carrier class involves a lot of low-value, repetitive,
error-prone code: constructors, accessors, `equals`, `hashCode`, `toString`, etc. For example,
a class to carry x and y coordinates inevitably ends up like this:
``` class Point { private final int x; private final int y;
Point(int x, int y) { this.x = x; this.y = y; }
int x() { return x; } int y() { return y; }
public boolean equals(Object o) { if (!(o instanceof Point)) return false;
Point other = (Point) o; return other.x == x && other.y == y; }
public int hashCode() { return Objects.hash(x, y); }
public String toString() { return String.format("Point[x=%d, y=%d]", x, y); } }
```
Developers are sometimes tempted to cut corners by omitting methods such as `equals`, leading
to surprising behavior or poor debuggability, or by pressing an alternate but not entirely
appropriate class into service because it has the "right shape" and they don't want to declare
yet another class.
IDEs help us to _write_ most of the code in a data-carrier class, but don't do anything to
help the _reader_ distill the design intent of "I'm a data carrier for `x` and `y`" from the
dozens of lines of boilerplate. Writing Java code that models a handful of values should be
easier to write, to read, and to verify as correct.
While it is superficially tempting to treat records as primarily being about boilerplate
reduction, we instead choose a more semantic goal: _modeling data as data_. (If the semantics
are right, the boilerplate will take care of itself.) It should be easy and concise to declare
data-carrier classes that _by default_ make their data immutable and provide idiomatic
implementations of methods that produce and consume the data.
Description --------
_Record classes_ are a new kind of class in the Java language. Record classes help to model
plain data aggregates with less ceremony than normal classes.
The declaration of a record class primarily consists of a declaration of its _state_; the
record class then commits to an API that matches that state. This means that record classes
give up a freedom that classes usually enjoy — the ability to decouple a class's API from its
internal representation — but, in return, record class declarations become significantly more
concise.
More precisely, a record class declaration consists of a name, optional type parameters, a
header, and a body. The header lists the _components_ of the record class, which are the
variables that make up its state. (This list of components is sometimes referred to as the
_state description_.) For example:
``` record Point(int x, int y) { } ```
Because record classes make the semantic claim of being transparent carriers for their data, a
record class acquires many standard members automatically:
- For each component in the header, two members: a `public` accessor method with the same name
and return type as the component, and a `private` `final` field with the same type as the
component;
- A _canonical constructor_ whose signature is the same as the header, and which assigns each
private field to the corresponding argument from a `new` expression which instantiates the
record;
- `equals` and `hashCode` methods which ensure that two record values are equal if they are of
the same type and contain equal component values; and
- A `toString` method that returns a string representation of all the record components, along
with their names.
In other words, the header of a record class describes its state, i.e., the types and names of
its components, and the API is derived mechanically and completely from that state
description. The API includes protocols for construction, member access, equality, and
display. (We expect a future version to support deconstruction patterns to allow powerful
pattern matching.)
### Constructors for record classes
The rules for constructors in a record class are different than in a normal class. A normal
class without any constructor declarations is automatically given a [_default
constructor_](https://docs.oracle.com/javase/specs/jls/se14/html/jls-8.html#jls-8.8.9). In
contrast, a record class without any constructor declarations is automatically given a
_canonical constructor_ that assigns all the private fields to the corresponding arguments of
the `new` expression which instantiated the record. For example, the record declared earlier —
`record Point(int x, int y) { }` — is compiled as if it were:
``` record Point(int x, int y) { // Implicitly declared fields private final int x;
private final int y;
// Other implicit declarations elided ...
// Implicitly declared canonical constructor Point(int x, int y) { this.x = x;
this.y = y; } } ```
The canonical constructor may be declared explicitly with a list of formal parameters which
match the record header, as shown above. It may also be declared more compactly, by eliding
the list of formal parameters. In such a _compact canonical constructor_ the parameters are
declared implicitly, and the private fields corresponding to record components cannot be
assigned in the body but are automatically assigned to the corresponding formal parameter
(`this.x = x;`) at the end of the constructor. The compact form helps developers focus on
validating and normalizing parameters without the tedious work of assigning parameters to
fields.
For example, here is a compact canonical constructor that validates its implicit formal
parameters:
``` record Range(int lo, int hi) { Range { if (lo > hi) // referring here to the
implicit constructor parameters throw new
IllegalArgumentException(String.format("(%d,%d)", lo, hi)); } } ```
Here is a compact canonical constructor that normalizes its formal parameters:
``` record Rational(int num, int denom) { Rational { int gcd = gcd(num, denom);
num /= gcd; denom /= gcd; } } ```
This declaration is equivalent to the conventional constructor form:
``` record Rational(int num, int denom) { Rational(int num, int demon) { //
Normalization int gcd = gcd(num, denom); num /= gcd; denom /= gcd;
// Initialization this.num = num; this.denom = denom; } } ```
Record classes with implicitly declared constructors and methods satisfy important, and
intuitive, semantic properties. For example, consider a record class `R` declared as follows:
``` record R(T1 c1, ..., Tn cn){ } ``` If an instance `r1` of `R` is copied in the following
way:
``` R r2 = new R(r1.c1(), r1.c2(), ..., r1.cn()); ```
then, assuming `r1` is not the null reference, it is _always_ the case that the expression
`r1.equals(r2)` will evaluate to `true`. Explicitly declared accessor and `equals` methods
should respect this invariant. However, it is not generally possible for a compiler to check
that explicitly declared methods respect this invariant.
As an example, the following declaration of a record class should be considered bad style
because its accessor methods "silently" adjust the state of a record instance, and the
invariant above is not satisfied:
``` record SmallPoint(int x, int y) { public int x() { return this.x < 100 ? this.x : 100; }
public int y() { return this.y < 100 ? this.y : 100; } } ``` In addition, for all record
classes the implicitly declared `equals` method is implemented so that it is reflexive and
that it behaves consistently with `hashCode` for record classes that have floating point
components. Again, explicitly declared `equals` and `hashCode` methods should behave
similarly.
### Rules for record classes
There are numerous restrictions on the declaration of a record class in comparison to a normal
class:
- A record class declaration does not have an `extends` clause. The superclass of a record
class is always `java.lang.Record`, similar to how the superclass of an enum class is always
`java.lang.Enum`. Even though a normal class can explicitly extend its implicit superclass
`Object`, a record cannot explicitly extend any class, even its implicit superclass `Record`.
- A record class is implicitly `final`, and cannot be `abstract`. These restrictions emphasize
that the API of a record class is defined solely by its state description, and cannot be
enhanced later by another class.
- The fields derived from the record components are `final`. This restriction embodies an
_immutable by default_ policy that is widely applicable for data-carrier classes.
- A record class cannot explicitly declare instance fields, and cannot contain instance
initializers. These restrictions ensure that the record header alone defines the state of a
record value.
- Any explicit declarations of a member that would otherwise be automatically derived must
match the type of the automatically derived member exactly, disregarding any annotations on
the explicit declaration. Any explicit implementation of accessors or the `equals` or
`hashCode` methods should be careful to preserve the semantic invariants of the record class.
- A record class cannot declare `native` methods. If a record class could declare a `native`
method then the behavior of the record class would by definition depend on external state
rather than the record class's explicit state. No class with native methods is likely to be a
good candidate for migration to a record.
Beyond the restrictions above, a record class behaves like a normal class:
- Instances of record classes are created using a `new` expression.
- A record class can be declared top level or nested, and can be generic.
- A record class can declare `static` methods, fields, and initializers.
- A record class can declare instance methods.
- A record class can implement interfaces. A record class cannot specify a superclass since
that would mean inherited state, beyond the state described in the header. A record class
can, however, freely specify superinterfaces and declare instance methods to implement them.
Just as for classes, an interface can usefully characterize the behavior of many records. The
behavior may be domain-independent (e.g., `Comparable`) or domain-specific, in which case
records can be part of a _sealed_ hierarchy which captures the domain (see below).
- A record class can declare nested types, including nested record classes. If a record class
is itself nested, then it is implicitly static; this avoids an immediately enclosing instance
which would silently add state to the record class.
- A record class, and the components in its header, may be decorated with annotations. Any
annotations on the record components are propagated to the automatically derived fields,
methods, and constructor parameters, according to the set of applicable targets for the
annotation. Type annotations on the types of record components are also propagated to the
corresponding type uses in the automatically derived members.
- Instances of record classes can be serialized and deserialized. However, the process cannot
be customized by providing `writeObject`, `readObject`, `readObjectNoData`, `writeExternal`,
or `readExternal` methods. The components of a record class govern serialization, while the
canonical constructor of a record class governs deserialization.
### Local record classes
A program that produces and consumes instances of a record class is likely to deal with many
intermediate values that are themselves simple groups of variables. It will often be
convenient to declare record classes to model those intermediate values. One option is to
declare "helper" record classes that are static and nested, much as many programs declare
helper classes today. A more convenient option would be to declare a record _inside a method_,
close to the code which manipulates the variables. Accordingly we define _local record
classes_, akin to the existing construct of [local
classes](https://docs.oracle.com/javase/specs/jls/se14/html/jls-14.html#jls-14.3).
In the following example, the aggregation of a merchant and a monthly sales figure is modeled
with a local record class, `MerchantSales`. Using this record class improves the readability
of the stream operations which follow:
``` List findTopMerchants(List merchants, int month) { // Local record
record MerchantSales(Merchant merchant, double sales) {}
return merchants.stream() .map(merchant -> new MerchantSales(merchant,
computeSales(merchant, month))) .sorted((m1, m2) -> Double.compare(m2.sales(),
m1.sales())) .map(MerchantSales::merchant) .collect(toList()); } ```
Local record classes are a particular case of nested record classes. Like nested record
classes, local record classes are _implicitly static_. This means that their own methods
cannot access any variables of the enclosing method; in turn, this avoids capturing an
immediately enclosing instance which would silently add state to the record class. The fact
that local record classes are implicitly static is in contrast to local classes, which are not
implicitly static. In fact, local classes are never static — implicitly or explicitly — and
can always access variables in the enclosing method.
### Local enum classes and local interfaces
The addition of local record classes is an opportunity to add other kinds of implicitly-static
local declarations.
Nested enum classes and nested interfaces are already implicitly static, so for consistency we
define local enum classes and local interfaces, which are also implicitly static.
### Static members of inner classes
It is [currently
specified](https://docs.oracle.com/javase/specs/jls/se14/html/jls-8.html#jls-8.1.3) to be a
compile-time error if an inner class declares a member that is explicitly or implicitly
static, unless the member is a constant variable. This means that, for example, an inner class
cannot declare a record class member, since nested record classes are implicitly static.
We relax this restriction in order to allow an inner class to declare members that are either
explicitly or implicitly static. In particular, this allows an inner class to declare a static
member that is a record class.
### Annotations on record components
Record components have multiple roles in record declarations. A record component is a
first-class concept, but each component also corresponds to a field of the same name and type,
an accessor method of the same name and return type, and a formal parameter of the canonical
constructor of the same name and type.
This raises the question: When a component is annotated, what actually is being annotated?
The answer is, "all of the elements to which this particular annotation is applicable." This
enables classes that use annotations on their fields, constructor parameters, or accessor
methods to be migrated to records without having to redundantly declare these members. For
example, a class such as the following
``` public final class Card { private final @MyAnno Rank rank; private final @MyAnno
Suit suit; @MyAnno Rank rank() { return this.rank; } @MyAnno Suit suit() { return
this.suit; } ... } ``` can be migrated to the equivalent, and considerably more readable,
record declaration:
``` public record Card(@MyAnno Rank rank, @MyAnno Suit suit) { ... } ```
The applicability of an annotation is declared using a `@Target` meta-annotation. Consider the
following:
``` @Target(ElementType.FIELD) public @interface I1 {...} ```
This declares the annotation `@I1` that it is applicable to field declarations. We can declare
that an annotation is applicable to more than one declaration; for example:
``` @Target({ElementType.FIELD, ElementType.METHOD}) public @interface I2 {...} ```
This declares an annotation `@I2` that it is applicable to both field declarations and method
declarations.
Returning to annotations on a record component, these annotations appear at the corresponding
program points where they are applicable. In other words, the propagation is under the control
of the developer using the `@Target` meta-annotation. The propagation rules are systematic and
intuitive, and all that apply are followed:
- If an annotation on a record component is applicable to a field declaration, then the
annotation appears on the corresponding private field.
- If an annotation on a record component is applicable to a method declaration, then the
annotation appears on the corresponding accessor method.
- If an annotation on a record component is applicable to a formal parameter, then the
annotation appears on the corresponding formal parameter of the canonical constructor if one
is not declared explicitly, or else to the corresponding formal parameter of the compact
constructor if one is declared explicitly.
- If an annotation on a record component is applicable to a type, the annotation will be
propagated to all of the following: - the type of the corresponding field - the return
type of the corresponding accessor method - the type of the corresponding formal parameter
of the canonical constructor - the type of the record component (which is accessible at
runtime via reflection)
If a public accessor method or (non-compact) canonical constructor is declared explicitly,
then it only has the annotations which appear on it directly; nothing is propagated from the
corresponding record component to these members.
A declaration annotation on a record component will not be amongst those associated with the
record component at run time via the [reflection API](#Reflection-API) unless the annotation
is meta-annotated with `@Target(RECORD_COMPONENT)`.
### Compatibility and migration
The abstract class `java.lang.Record` is the common superclass of all record classes. Every
Java source file implicitly imports the `java.lang.Record` class, as well as all other types
in the `java.lang` package, regardless of whether you enable or disable preview features.
However, if your application imports another class named `Record` from a different package,
you might get a compiler error.
Consider the following class declaration of `com.myapp.Record`:
``` package com.myapp;
public class Record { public String greeting; public Record(String greeting) {
this.greeting = greeting; } } ```
The following example, `org.example.MyappPackageExample`, imports `com.myapp.Record` with a
wildcard but doesn't compile:
``` package org.example; import com.myapp.*;
public class MyappPackageExample { public static void main(String[] args) { Record
r = new Record("Hello world!"); } } ```
The compiler generates an error message similar to the following:
``` ./org/example/MyappPackageExample.java:6: error: reference to Record is ambiguous
Record r = new Record("Hello world!"); ^ both class com.myapp.Record in com.myapp and
class java.lang.Record in java.lang match
./org/example/MyappPackageExample.java:6: error: reference to Record is ambiguous
Record r = new Record("Hello world!"); ^ both class com.myapp.Record
in com.myapp and class java.lang.Record in java.lang match ```
Both `Record` in the `com.myapp` package and `Record` in the `java.lang` package are imported
with wildcards. Consequently, neither class takes precedence, and the compiler generates an
error message when it encounters the use of the simple name `Record`.
To enable this example to compile, the `import` statement can be changed so that it imports
the fully qualified name of `Record`:
``` import com.myapp.Record; ```
The introduction of classes in the `java.lang` package is rare but sometimes necessary.
Previous examples are `Enum` in Java 5, `Module` in Java 9, and `Record` in
Java 14.
### Java grammar
``` RecordDeclaration: {ClassModifier} `record` TypeIdentifier [TypeParameters]
RecordHeader [SuperInterfaces] RecordBody
RecordHeader: `(` [RecordComponentList] `)`
RecordComponentList: RecordComponent { `,` RecordComponent}
RecordComponent: {Annotation} UnannType Identifier VariableArityRecordComponent
VariableArityRecordComponent: {Annotation} UnannType {Annotation} `...` Identifier
RecordBody: `{` {RecordBodyDeclaration} `}`
RecordBodyDeclaration: ClassBodyDeclaration CompactConstructorDeclaration
CompactConstructorDeclaration: {ConstructorModifier} SimpleTypeName ConstructorBody ```
### Class-file representation
The `class` file of a record uses a `Record` attribute to store information about the record's
components:
``` Record_attribute { u2 attribute_name_index; u4 attribute_length; u2
components_count; record_component_info components[components_count]; }
record_component_info { u2 name_index; u2 descriptor_index; u2 attributes_count;
attribute_info attributes[attributes_count]; } ```
If the record component has a generic signature that is different from the erased descriptor
then there must be a `Signature` attribute in the `record_component_info` structure.
### Reflection API
We add two public methods to `java.lang.Class`:
- `RecordComponent[] getRecordComponents()` — Returns an array of
`java.lang.reflect.RecordComponent` objects. The elements of this array correspond to the
record's components, in the same order as they appear in the record declaration. Additional
information can be extracted from each element of the array, including its name, annotations,
and accessor method.
- `boolean isRecord()` — Returns true if the given class was declared as a record. (Compare
with `isEnum`.)
Alternatives --------
Record classes can be considered a nominal form of _tuples_. Instead of record classes, we
could implement structural tuples. However, while tuples might offer a lightweight means of
expressing some aggregates, the result is often inferior aggregates:
- A central aspect of Java's design philosophy is that _names matter_. Classes and their
members have meaningful names, while tuples and tuple components do not. That is, a `Person`
record class with components `firstName` and `lastName` is clearer and safer than an anonymous
tuple of two strings.
- Classes allow for state validation through their constructors; tuples typically do not. Some
data aggregates (such as numeric ranges) have invariants that, if enforced by the constructor,
can thereafter be relied upon. Tuples do not offer this ability.
- Classes can have behavior that is based on their state; co-locating the state and behavior
makes the behavior more discoverable and easier to access. Tuples, being raw data, offer no
such facility.
Dependencies --------
Record classes work well with another feature currently in preview, namely _sealed classes_
([JEP 360](https://openjdk.java.net/jeps/360)). For example, a family of record classes can be
explicitly declared to implement the same sealed interface:
``` package com.example.expression;
public sealed interface Expr permits ConstantExpr, PlusExpr, TimesExpr, NegExpr {...}
public record ConstantExpr(int i) implements Expr {...} public record PlusExpr(Expr a,
Expr b) implements Expr {...} public record TimesExpr(Expr a, Expr b) implements Expr {...}
public record NegExpr(Expr e) implements Expr {...} ```
The combination of record classes and sealed classes is sometimes referred to as [_algebraic
data types_](https://en.wikipedia.org/wiki/Algebraic_data_type). Record classes allow us to
express _products_, and sealed classes allow us to express _sums_.
In addition to the combination of record classes and sealed classes, record classes lend
themselves naturally to [pattern matching][patterns]. Because record classes couple their API
to their state description, we will eventually be able to derive deconstruction patterns for
record classes as well, and use sealed type information to determine exhaustiveness in
`switch` expressions with type patterns or deconstruction patterns.
[patterns]: https://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html [sealed]:
https://openjdk.java.net/jeps/360 [adts]: https://en.wikipedia.org/wiki/Algebraic_data_type
JDK-8236439: JEP 359: Records (Preview)
In JDK 14, the [Records (JEP 359)](https://openjdk.java.net/jeps/359) preview feature adds a
new class `java.lang.Record`. The `java.lang` package is implicitly imported on demand, that
is, `import java.lang.*`. If code in an existing source file imports some other package on
demand, for example, `import com.myapp.*;`, and that other package declares a type called
`Record`, then code in the existing source file which refers to that type will not compile
without change. To make the code compile, import the other package's `Record` type using a
single-type import, for example, `import com.myapp.Record;`.
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-8246771: JEP 395: Records
Summary --------
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_.
[records]: http://cr.openjdk.java.net/~briangoetz/amber/datum.html
History --------
Records were proposed by [JEP 359](https://openjdk.java.net/jeps/359) and delivered in [JDK
14](https://openjdk.java.net/projects/jdk/14) as a [preview
feature](http://openjdk.java.net/jeps/12).
In response to feedback, the design was refined by [JEP
384](https://openjdk.java.net/jeps/384) and delivered in [JDK
15](https://openjdk.java.net/projects/jdk/15) as a preview feature for a second time. The
refinements for the second preview were as follows:
- In the first preview, canonical constructors were required to be `public`. In the second
preview, if the canonical constructor is implicitly declared then its access modifier is the
same as the record class; if the canonical constructor is explicitly declared then its access
modifier must provide at least as much access as the record class.
- The meaning of the `@Override` annotation was extended to include the case where the
annotated method is an explicitly declared accessor method for a record component.
- To enforce the intended use of compact constructors, it became a compile-time error to
assign to any of the instance fields in the constructor body.
- The ability to declare local record classes, local enum classes, and local interfaces was
introduced.
This JEP proposes to finalize the feature in JDK 16, with the following refinement:
- Relax the longstanding restriction whereby an inner class cannot declare a member that is
explicitly or implicitly static. This will become legal and, in particular, will allow an
inner class to declare a member that is a record class.
Additional refinements may be incorporated based on further feedback.
Goals --------
- Devise an object-oriented construct that expresses a simple aggregation of values.
- Help developers to focus on modeling immutable data rather than extensible behavior.
- Automatically implement data-driven methods such as `equals` and accessors.
- Preserve long-standing Java principles such as nominal typing and migration compatibility.
Non-Goals --------
- While records do offer improved concision when declaring data carrier classes, it is not a
goal to declare a "war on boilerplate". In particular, it is not a goal to address the
problems of mutable classes which use the JavaBeans naming conventions.
- It is not a goal to add features such as properties or annotation-driven code generation,
which are often proposed to streamline the declaration of classes for "Plain Old Java
Objects".
Motivation --------
It is a common complaint that "Java is too verbose" or has "too much ceremony". Some of the
worst offenders are classes that are nothing more than immutable _data carriers_ for a handful
of values. Properly writing such a data-carrier class involves a lot of low-value, repetitive,
error-prone code: constructors, accessors, `equals`, `hashCode`, `toString`, etc. For example,
a class to carry x and y coordinates inevitably ends up like this:
``` class Point { private final int x; private final int y;
Point(int x, int y) { this.x = x; this.y = y; }
int x() { return x; } int y() { return y; }
public boolean equals(Object o) { if (!(o instanceof Point)) return false;
Point other = (Point) o; return other.x == x && other.y == y; }
public int hashCode() { return Objects.hash(x, y); }
public String toString() { return String.format("Point[x=%d, y=%d]", x, y); } }
```
Developers are sometimes tempted to cut corners by omitting methods such as `equals`, leading
to surprising behavior or poor debuggability, or by pressing an alternate but not entirely
appropriate class into service because it has the "right shape" and they don't want to declare
yet another class.
IDEs help us to _write_ most of the code in a data-carrier class, but don't do anything to
help the _reader_ distill the design intent of "I'm a data carrier for `x` and `y`" from the
dozens of lines of boilerplate. Writing Java code that models a handful of values should be
easier to write, to read, and to verify as correct.
While it is superficially tempting to treat records as primarily being about boilerplate
reduction, we instead choose a more semantic goal: _modeling data as data_. (If the semantics
are right, the boilerplate will take care of itself.) It should be easy and concise to declare
data-carrier classes that _by default_ make their data immutable and provide idiomatic
implementations of methods that produce and consume the data.
Description --------
_Record classes_ are a new kind of class in the Java language. Record classes help to model
plain data aggregates with less ceremony than normal classes.
The declaration of a record class primarily consists of a declaration of its _state_; the
record class then commits to an API that matches that state. This means that record classes
give up a freedom that classes usually enjoy — the ability to decouple a class's API from its
internal representation — but, in return, record class declarations become significantly more
concise.
More precisely, a record class declaration consists of a name, optional type parameters, a
header, and a body. The header lists the _components_ of the record class, which are the
variables that make up its state. (This list of components is sometimes referred to as the
_state description_.) For example:
``` record Point(int x, int y) { } ```
Because record classes make the semantic claim of being transparent carriers for their data, a
record class acquires many standard members automatically:
- For each component in the header, two members: a `public` accessor method with the same name
and return type as the component, and a `private` `final` field with the same type as the
component;
- A _canonical constructor_ whose signature is the same as the header, and which assigns each
private field to the corresponding argument from a `new` expression which instantiates the
record;
- `equals` and `hashCode` methods which ensure that two record values are equal if they are of
the same type and contain equal component values; and
- A `toString` method that returns a string representation of all the record components, along
with their names.
In other words, the header of a record class describes its state, i.e., the types and names of
its components, and the API is derived mechanically and completely from that state
description. The API includes protocols for construction, member access, equality, and
display. (We expect a future version to support deconstruction patterns to allow powerful
pattern matching.)
### Constructors for record classes
The rules for constructors in a record class are different than in a normal class. A normal
class without any constructor declarations is automatically given a [_default
constructor_](https://docs.oracle.com/javase/specs/jls/se14/html/jls-8.html#jls-8.8.9). In
contrast, a record class without any constructor declarations is automatically given a
_canonical constructor_ that assigns all the private fields to the corresponding arguments of
the `new` expression which instantiated the record. For example, the record declared earlier —
`record Point(int x, int y) { }` — is compiled as if it were:
``` record Point(int x, int y) { // Implicitly declared fields private final int x;
private final int y;
// Other implicit declarations elided ...
// Implicitly declared canonical constructor Point(int x, int y) { this.x = x;
this.y = y; } } ```
The canonical constructor may be declared explicitly with a list of formal parameters which
match the record header, as shown above. It may also be declared more compactly, by eliding
the list of formal parameters. In such a _compact canonical constructor_ the parameters are
declared implicitly, and the private fields corresponding to record components cannot be
assigned in the body but are automatically assigned to the corresponding formal parameter
(`this.x = x;`) at the end of the constructor. The compact form helps developers focus on
validating and normalizing parameters without the tedious work of assigning parameters to
fields.
For example, here is a compact canonical constructor that validates its implicit formal
parameters:
``` record Range(int lo, int hi) { Range { if (lo > hi) // referring here to the
implicit constructor parameters throw new
IllegalArgumentException(String.format("(%d,%d)", lo, hi)); } } ```
Here is a compact canonical constructor that normalizes its formal parameters:
``` record Rational(int num, int denom) { Rational { int gcd = gcd(num, denom);
num /= gcd; denom /= gcd; } } ```
This declaration is equivalent to the conventional constructor form:
``` record Rational(int num, int denom) { Rational(int num, int demon) { //
Normalization int gcd = gcd(num, denom); num /= gcd; denom /= gcd;
// Initialization this.num = num; this.denom = denom; } } ```
Record classes with implicitly declared constructors and methods satisfy important, and
intuitive, semantic properties. For example, consider a record class `R` declared as follows:
``` record R(T1 c1, ..., Tn cn){ } ``` If an instance `r1` of `R` is copied in the following
way:
``` R r2 = new R(r1.c1(), r1.c2(), ..., r1.cn()); ```
then, assuming `r1` is not the null reference, it is _always_ the case that the expression
`r1.equals(r2)` will evaluate to `true`. Explicitly declared accessor and `equals` methods
should respect this invariant. However, it is not generally possible for a compiler to check
that explicitly declared methods respect this invariant.
As an example, the following declaration of a record class should be considered bad style
because its accessor methods "silently" adjust the state of a record instance, and the
invariant above is not satisfied:
``` record SmallPoint(int x, int y) { public int x() { return this.x < 100 ? this.x : 100; }
public int y() { return this.y < 100 ? this.y : 100; } } ``` In addition, for all record
classes the implicitly declared `equals` method is implemented so that it is reflexive and
that it behaves consistently with `hashCode` for record classes that have floating point
components. Again, explicitly declared `equals` and `hashCode` methods should behave
similarly.
### Rules for record classes
There are numerous restrictions on the declaration of a record class in comparison to a normal
class:
- A record class declaration does not have an `extends` clause. The superclass of a record
class is always `java.lang.Record`, similar to how the superclass of an enum class is always
`java.lang.Enum`. Even though a normal class can explicitly extend its implicit superclass
`Object`, a record cannot explicitly extend any class, even its implicit superclass `Record`.
- A record class is implicitly `final`, and cannot be `abstract`. These restrictions emphasize
that the API of a record class is defined solely by its state description, and cannot be
enhanced later by another class.
- The fields derived from the record components are `final`. This restriction embodies an
_immutable by default_ policy that is widely applicable for data-carrier classes.
- A record class cannot explicitly declare instance fields, and cannot contain instance
initializers. These restrictions ensure that the record header alone defines the state of a
record value.
- Any explicit declarations of a member that would otherwise be automatically derived must
match the type of the automatically derived member exactly, disregarding any annotations on
the explicit declaration. Any explicit implementation of accessors or the `equals` or
`hashCode` methods should be careful to preserve the semantic invariants of the record class.
- A record class cannot declare `native` methods. If a record class could declare a `native`
method then the behavior of the record class would by definition depend on external state
rather than the record class's explicit state. No class with native methods is likely to be a
good candidate for migration to a record.
Beyond the restrictions above, a record class behaves like a normal class:
- Instances of record classes are created using a `new` expression.
- A record class can be declared top level or nested, and can be generic.
- A record class can declare `static` methods, fields, and initializers.
- A record class can declare instance methods.
- A record class can implement interfaces. A record class cannot specify a superclass since
that would mean inherited state, beyond the state described in the header. A record class
can, however, freely specify superinterfaces and declare instance methods to implement them.
Just as for classes, an interface can usefully characterize the behavior of many records. The
behavior may be domain-independent (e.g., `Comparable`) or domain-specific, in which case
records can be part of a _sealed_ hierarchy which captures the domain (see below).
- A record class can declare nested types, including nested record classes. If a record class
is itself nested, then it is implicitly static; this avoids an immediately enclosing instance
which would silently add state to the record class.
- A record class, and the components in its header, may be decorated with annotations. Any
annotations on the record components are propagated to the automatically derived fields,
methods, and constructor parameters, according to the set of applicable targets for the
annotation. Type annotations on the types of record components are also propagated to the
corresponding type uses in the automatically derived members.
- Instances of record classes can be serialized and deserialized. However, the process cannot
be customized by providing `writeObject`, `readObject`, `readObjectNoData`, `writeExternal`,
or `readExternal` methods. The components of a record class govern serialization, while the
canonical constructor of a record class governs deserialization.
### Local record classes
A program that produces and consumes instances of a record class is likely to deal with many
intermediate values that are themselves simple groups of variables. It will often be
convenient to declare record classes to model those intermediate values. One option is to
declare "helper" record classes that are static and nested, much as many programs declare
helper classes today. A more convenient option would be to declare a record _inside a method_,
close to the code which manipulates the variables. Accordingly we define _local record
classes_, akin to the existing construct of [local
classes](https://docs.oracle.com/javase/specs/jls/se14/html/jls-14.html#jls-14.3).
In the following example, the aggregation of a merchant and a monthly sales figure is modeled
with a local record class, `MerchantSales`. Using this record class improves the readability
of the stream operations which follow:
``` List findTopMerchants(List merchants, int month) { // Local record
record MerchantSales(Merchant merchant, double sales) {}
return merchants.stream() .map(merchant -> new MerchantSales(merchant,
computeSales(merchant, month))) .sorted((m1, m2) -> Double.compare(m2.sales(),
m1.sales())) .map(MerchantSales::merchant) .collect(toList()); } ```
Local record classes are a particular case of nested record classes. Like nested record
classes, local record classes are _implicitly static_. This means that their own methods
cannot access any variables of the enclosing method; in turn, this avoids capturing an
immediately enclosing instance which would silently add state to the record class. The fact
that local record classes are implicitly static is in contrast to local classes, which are not
implicitly static. In fact, local classes are never static — implicitly or explicitly — and
can always access variables in the enclosing method.
### Local enum classes and local interfaces
The addition of local record classes is an opportunity to add other kinds of implicitly-static
local declarations.
Nested enum classes and nested interfaces are already implicitly static, so for consistency we
define local enum classes and local interfaces, which are also implicitly static.
### Static members of inner classes
It is [currently
specified](https://docs.oracle.com/javase/specs/jls/se14/html/jls-8.html#jls-8.1.3) to be a
compile-time error if an inner class declares a member that is explicitly or implicitly
static, unless the member is a constant variable. This means that, for example, an inner class
cannot declare a record class member, since nested record classes are implicitly static.
We relax this restriction in order to allow an inner class to declare members that are either
explicitly or implicitly static. In particular, this allows an inner class to declare a static
member that is a record class.
### Annotations on record components
Record components have multiple roles in record declarations. A record component is a
first-class concept, but each component also corresponds to a field of the same name and type,
an accessor method of the same name and return type, and a formal parameter of the canonical
constructor of the same name and type.
This raises the question: When a component is annotated, what actually is being annotated?
The answer is, "all of the elements to which this particular annotation is applicable." This
enables classes that use annotations on their fields, constructor parameters, or accessor
methods to be migrated to records without having to redundantly declare these members. For
example, a class such as the following
``` public final class Card { private final @MyAnno Rank rank; private final @MyAnno
Suit suit; @MyAnno Rank rank() { return this.rank; } @MyAnno Suit suit() { return
this.suit; } ... } ``` can be migrated to the equivalent, and considerably more readable,
record declaration:
``` public record Card(@MyAnno Rank rank, @MyAnno Suit suit) { ... } ```
The applicability of an annotation is declared using a `@Target` meta-annotation. Consider the
following:
``` @Target(ElementType.FIELD) public @interface I1 {...} ```
This declares the annotation `@I1` that it is applicable to field declarations. We can declare
that an annotation is applicable to more than one declaration; for example:
``` @Target({ElementType.FIELD, ElementType.METHOD}) public @interface I2 {...} ```
This declares an annotation `@I2` that it is applicable to both field declarations and method
declarations.
Returning to annotations on a record component, these annotations appear at the corresponding
program points where they are applicable. In other words, the propagation is under the control
of the developer using the `@Target` meta-annotation. The propagation rules are systematic and
intuitive, and all that apply are followed:
- If an annotation on a record component is applicable to a field declaration, then the
annotation appears on the corresponding private field.
- If an annotation on a record component is applicable to a method declaration, then the
annotation appears on the corresponding accessor method.
- If an annotation on a record component is applicable to a formal parameter, then the
annotation appears on the corresponding formal parameter of the canonical constructor if one
is not declared explicitly, or else to the corresponding formal parameter of the compact
constructor if one is declared explicitly.
- If an annotation on a record component is applicable to a type, the annotation will be
propagated to all of the following: - the type of the corresponding field - the return
type of the corresponding accessor method - the type of the corresponding formal parameter
of the canonical constructor - the type of the record component (which is accessible at
runtime via reflection)
If a public accessor method or (non-compact) canonical constructor is declared explicitly,
then it only has the annotations which appear on it directly; nothing is propagated from the
corresponding record component to these members.
A declaration annotation on a record component will not be amongst those associated with the
record component at run time via the [reflection API](#Reflection-API) unless the annotation
is meta-annotated with `@Target(RECORD_COMPONENT)`.
### Compatibility and migration
The abstract class `java.lang.Record` is the common superclass of all record classes. Every
Java source file implicitly imports the `java.lang.Record` class, as well as all other types
in the `java.lang` package, regardless of whether you enable or disable preview features.
However, if your application imports another class named `Record` from a different package,
you might get a compiler error.
Consider the following class declaration of `com.myapp.Record`:
``` package com.myapp;
public class Record { public String greeting; public Record(String greeting) {
this.greeting = greeting; } } ```
The following example, `org.example.MyappPackageExample`, imports `com.myapp.Record` with a
wildcard but doesn't compile:
``` package org.example; import com.myapp.*;
public class MyappPackageExample { public static void main(String[] args) { Record
r = new Record("Hello world!"); } } ```
The compiler generates an error message similar to the following:
``` ./org/example/MyappPackageExample.java:6: error: reference to Record is ambiguous
Record r = new Record("Hello world!"); ^ both class com.myapp.Record in com.myapp and
class java.lang.Record in java.lang match
./org/example/MyappPackageExample.java:6: error: reference to Record is ambiguous
Record r = new Record("Hello world!"); ^ both class com.myapp.Record
in com.myapp and class java.lang.Record in java.lang match ```
Both `Record` in the `com.myapp` package and `Record` in the `java.lang` package are imported
with wildcards. Consequently, neither class takes precedence, and the compiler generates an
error message when it encounters the use of the simple name `Record`.
To enable this example to compile, the `import` statement can be changed so that it imports
the fully qualified name of `Record`:
``` import com.myapp.Record; ```
The introduction of classes in the `java.lang` package is rare but sometimes necessary.
Previous examples are `Enum` in Java 5, `Module` in Java 9, and `Record` in
Java 14.
### Java grammar
``` RecordDeclaration: {ClassModifier} `record` TypeIdentifier [TypeParameters]
RecordHeader [SuperInterfaces] RecordBody
RecordHeader: `(` [RecordComponentList] `)`
RecordComponentList: RecordComponent { `,` RecordComponent}
RecordComponent: {Annotation} UnannType Identifier VariableArityRecordComponent
VariableArityRecordComponent: {Annotation} UnannType {Annotation} `...` Identifier
RecordBody: `{` {RecordBodyDeclaration} `}`
RecordBodyDeclaration: ClassBodyDeclaration CompactConstructorDeclaration
CompactConstructorDeclaration: {ConstructorModifier} SimpleTypeName ConstructorBody ```
### Class-file representation
The `class` file of a record uses a `Record` attribute to store information about the record's
components:
``` Record_attribute { u2 attribute_name_index; u4 attribute_length; u2
components_count; record_component_info components[components_count]; }
record_component_info { u2 name_index; u2 descriptor_index; u2 attributes_count;
attribute_info attributes[attributes_count]; } ```
If the record component has a generic signature that is different from the erased descriptor
then there must be a `Signature` attribute in the `record_component_info` structure.
### Reflection API
We add two public methods to `java.lang.Class`:
- `RecordComponent[] getRecordComponents()` — Returns an array of
`java.lang.reflect.RecordComponent` objects. The elements of this array correspond to the
record's components, in the same order as they appear in the record declaration. Additional
information can be extracted from each element of the array, including its name, annotations,
and accessor method.
- `boolean isRecord()` — Returns true if the given class was declared as a record. (Compare
with `isEnum`.)
Alternatives --------
Record classes can be considered a nominal form of _tuples_. Instead of record classes, we
could implement structural tuples. However, while tuples might offer a lightweight means of
expressing some aggregates, the result is often inferior aggregates:
- A central aspect of Java's design philosophy is that _names matter_. Classes and their
members have meaningful names, while tuples and tuple components do not. That is, a `Person`
record class with components `firstName` and `lastName` is clearer and safer than an anonymous
tuple of two strings.
- Classes allow for state validation through their constructors; tuples typically do not. Some
data aggregates (such as numeric ranges) have invariants that, if enforced by the constructor,
can thereafter be relied upon. Tuples do not offer this ability.
- Classes can have behavior that is based on their state; co-locating the state and behavior
makes the behavior more discoverable and easier to access. Tuples, being raw data, offer no
such facility.
Dependencies --------
Record classes work well with another feature currently in preview, namely _sealed classes_
([JEP 360](https://openjdk.java.net/jeps/360)). For example, a family of record classes can be
explicitly declared to implement the same sealed interface:
``` package com.example.expression;
public sealed interface Expr permits ConstantExpr, PlusExpr, TimesExpr, NegExpr {...}
public record ConstantExpr(int i) implements Expr {...} public record PlusExpr(Expr a,
Expr b) implements Expr {...} public record TimesExpr(Expr a, Expr b) implements Expr {...}
public record NegExpr(Expr e) implements Expr {...} ```
The combination of record classes and sealed classes is sometimes referred to as [_algebraic
data types_](https://en.wikipedia.org/wiki/Algebraic_data_type). Record classes allow us to
express _products_, and sealed classes allow us to express _sums_.
In addition to the combination of record classes and sealed classes, record classes lend
themselves naturally to [pattern matching][patterns]. Because record classes couple their API
to their state description, we will eventually be able to derive deconstruction patterns for
record classes as well, and use sealed type information to determine exhaustiveness in
`switch` expressions with type patterns or deconstruction patterns.
[patterns]: https://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html [sealed]:
https://openjdk.java.net/jeps/360 [adts]: https://en.wikipedia.org/wiki/Algebraic_data_type
JDK-8236439: JEP 359: Records (Preview)
In JDK 14, the [Records (JEP 359)](https://openjdk.java.net/jeps/359) preview feature adds a
new class `java.lang.Record`. The `java.lang` package is implicitly imported on demand, that
is, `import java.lang.*`. If code in an existing source file imports some other package on
demand, for example, `import com.myapp.*;`, and that other package declares a type called
`Record`, then code in the existing source file which refers to that type will not compile
without change. To make the code compile, import the other package's `Record` type using a
single-type import, for example, `import com.myapp.Record;`.
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/java.nio.charsets:
JDK-8230725: Removal of sun.nio.cs.map System Property
The system property `sun.nio.cs.map`, added in JDK 1.4.1, has been removed. It was provided
for applications to help migrate from the old definition of `Shift_JIS`, which was equivalent
to MS Windows codepage 932, to the one that is defined by IANA. Applications that are using
the mapping property will need to designate the correct charset name based on their needs.
hotspot/runtime:
JDK-8227417: Added -XX:+AdjustStackSizeForTLS Flag
The `glibc` library allocates some thread-local storage (TLS) in the stack of a newly created
thread, leaving less stack than requested for the thread to do its work. This is particularly
a problem for threads with small stack sizes. It is an inherited issue from a well-known
`glibc` problem, 'Program with large TLS segments fail' [0] and has been observed in Java
applications. In one of the reported JVM failure instances, the issue manifests as a
`StackOverflowError` on the process reaper thread, which has a small stack size. The
`java.lang.Thread` constructor enables users to specify the stack size for a new thread. The
created thread may encounter the TLS problem when the specified size is too small to
accommodate the on-stack TLS blocks.
In JDK 8, a system property, `jdk.lang.processReaperUseDefaultStackSize`, was introduced to
address the TLS issue only for reaper threads. Setting the property gives a bigger stack size
to the reaper threads.
To address the issue for all threads, a general purpose workaround was implemented in Java
which adjusts thread stack size for TLS. It can be enabled by using the
`AdjustStackSizeForTLS` command-line option:
` -XX:+AdjustStackSizeForTLS`
When creating a new thread, if `AdjustStackSizeForTLS` is true, the static TLS area size is
added to the user requested stack size. `AdjustStackSizeForTLS` is disabled by default.
Reference: [0] [Bug 11787 - Program with large TLS segments
fail](https://sourceware.org/bugzilla/show_bug.cgi?id=11787)
JDK-8234771: Thread Interrupt State Is Always Available
The specification for `java.lang.Thread::interrupt` allows for an implementation to only track
the interrupt state for live threads, and previously this is what occurred. As of this
release, the interrupt state of a `Thread` is always available, and if you interrupt a thread
`t` before it is started, or after it has terminated, the query `t.isInterrupted()` will
return true.
JDK-8234223: Detailed Message in NullPointerExceptions
A new option is available to provide more helpful `NullPointerException` messages:
-XX:+ShowCodeDetailsInExceptionMessages
If the option is set, on encountering a null pointer, the JVM analyzes the program to
determine which reference was `null` and then provides the details as part of
`NullPointerException.getMessage()`. In addition to the exception message, the method,
filename, and line number are also returned.
By default, this option is disabled.
JDK-8230291: CDS Behavior Change With Non-existent Files During Archive Creation
In JDK 14, CDS runtime classpath validation is now more forgiving when dealing with files in
the classpath that do not exist.
At CDS archive dump time, all non-existent elements in the classpath are automatically
stripped. For example, if the command is:
java -cp nosuchfile.jar:hello.jar -Xshare:dump \
-XX:SharedClassListFile=hello.classlist \ -XX:SharedArchiveFile=hello.jsa
after removing the non-existing elements, the classpath recorded in `hello.jsa` becomes
`hello.jar`.
Also, at run time, when the CDS archive is loaded, all non-existent elements in the classpath
are ignored. With the previous example, all of the following commands will successfully load
the archive:
(1) ``` java -cp nosuchfile.jar:hello.jar -Xshare:on \
-XX:SharedArchiveFile=hello.jsa \ Hello ``` (2) ``` java -cp hello.jar
-Xshare:on \ -XX:SharedArchiveFile=hello.jsa \ Hello ``` (3) ``` java
-cp alsonosuchfile.jar:hello.jar -Xshare:on \ -XX:SharedArchiveFile=hello.jsa \
Hello ```
In JDK 13 and earlier, only (1) is allowed while (2) and (3) would trigger an error.
JDK-8227417: Added -XX:+AdjustStackSizeForTLS Flag
The `glibc` library allocates some thread-local storage (TLS) in the stack of a newly created
thread, leaving less stack than requested for the thread to do its work. This is particularly
a problem for threads with small stack sizes. It is an inherited issue from a well-known
`glibc` problem, 'Program with large TLS segments fail' [0] and has been observed in Java
applications. In one of the reported JVM failure instances, the issue manifests as a
`StackOverflowError` on the process reaper thread, which has a small stack size. The
`java.lang.Thread` constructor enables users to specify the stack size for a new thread. The
created thread may encounter the TLS problem when the specified size is too small to
accommodate the on-stack TLS blocks.
In JDK 8, a system property, `jdk.lang.processReaperUseDefaultStackSize`, was introduced to
address the TLS issue only for reaper threads. Setting the property gives a bigger stack size
to the reaper threads.
To address the issue for all threads, a general purpose workaround was implemented in Java
which adjusts thread stack size for TLS. It can be enabled by using the
`AdjustStackSizeForTLS` command-line option:
` -XX:+AdjustStackSizeForTLS`
When creating a new thread, if `AdjustStackSizeForTLS` is true, the static TLS area size is
added to the user requested stack size. `AdjustStackSizeForTLS` is disabled by default.
Reference: [0] [Bug 11787 - Program with large TLS segments
fail](https://sourceware.org/bugzilla/show_bug.cgi?id=11787)
JDK-8234771: Thread Interrupt State Is Always Available
The specification for `java.lang.Thread::interrupt` allows for an implementation to only track
the interrupt state for live threads, and previously this is what occurred. As of this
release, the interrupt state of a `Thread` is always available, and if you interrupt a thread
`t` before it is started, or after it has terminated, the query `t.isInterrupted()` will
return true.
JDK-8234223: Detailed Message in NullPointerExceptions
A new option is available to provide more helpful `NullPointerException` messages:
-XX:+ShowCodeDetailsInExceptionMessages
If the option is set, on encountering a null pointer, the JVM analyzes the program to
determine which reference was `null` and then provides the details as part of
`NullPointerException.getMessage()`. In addition to the exception message, the method,
filename, and line number are also returned.
By default, this option is disabled.
JDK-8230291: CDS Behavior Change With Non-existent Files During Archive Creation
In JDK 14, CDS runtime classpath validation is now more forgiving when dealing with files in
the classpath that do not exist.
At CDS archive dump time, all non-existent elements in the classpath are automatically
stripped. For example, if the command is:
java -cp nosuchfile.jar:hello.jar -Xshare:dump \
-XX:SharedClassListFile=hello.classlist \ -XX:SharedArchiveFile=hello.jsa
after removing the non-existing elements, the classpath recorded in `hello.jsa` becomes
`hello.jar`.
Also, at run time, when the CDS archive is loaded, all non-existent elements in the classpath
are ignored. With the previous example, all of the following commands will successfully load
the archive:
(1) ``` java -cp nosuchfile.jar:hello.jar -Xshare:on \
-XX:SharedArchiveFile=hello.jsa \ Hello ``` (2) ``` java -cp hello.jar
-Xshare:on \ -XX:SharedArchiveFile=hello.jsa \ Hello ``` (3) ``` java
-cp alsonosuchfile.jar:hello.jar -Xshare:on \ -XX:SharedArchiveFile=hello.jsa \
Hello ```
In JDK 13 and earlier, only (1) is allowed while (2) and (3) would trigger an error.
JDK-8227417: Added -XX:+AdjustStackSizeForTLS Flag
The `glibc` library allocates some thread-local storage (TLS) in the stack of a newly created
thread, leaving less stack than requested for the thread to do its work. This is particularly
a problem for threads with small stack sizes. It is an inherited issue from a well-known
`glibc` problem, 'Program with large TLS segments fail' [0] and has been observed in Java
applications. In one of the reported JVM failure instances, the issue manifests as a
`StackOverflowError` on the process reaper thread, which has a small stack size. The
`java.lang.Thread` constructor enables users to specify the stack size for a new thread. The
created thread may encounter the TLS problem when the specified size is too small to
accommodate the on-stack TLS blocks.
In JDK 8, a system property, `jdk.lang.processReaperUseDefaultStackSize`, was introduced to
address the TLS issue only for reaper threads. Setting the property gives a bigger stack size
to the reaper threads.
To address the issue for all threads, a general purpose workaround was implemented in Java
which adjusts thread stack size for TLS. It can be enabled by using the
`AdjustStackSizeForTLS` command-line option:
` -XX:+AdjustStackSizeForTLS`
When creating a new thread, if `AdjustStackSizeForTLS` is true, the static TLS area size is
added to the user requested stack size. `AdjustStackSizeForTLS` is disabled by default.
Reference: [0] [Bug 11787 - Program with large TLS segments
fail](https://sourceware.org/bugzilla/show_bug.cgi?id=11787)
JDK-8234771: Thread Interrupt State Is Always Available
The specification for `java.lang.Thread::interrupt` allows for an implementation to only track
the interrupt state for live threads, and previously this is what occurred. As of this
release, the interrupt state of a `Thread` is always available, and if you interrupt a thread
`t` before it is started, or after it has terminated, the query `t.isInterrupted()` will
return true.
JDK-8234223: Detailed Message in NullPointerExceptions
A new option is available to provide more helpful `NullPointerException` messages:
-XX:+ShowCodeDetailsInExceptionMessages
If the option is set, on encountering a null pointer, the JVM analyzes the program to
determine which reference was `null` and then provides the details as part of
`NullPointerException.getMessage()`. In addition to the exception message, the method,
filename, and line number are also returned.
By default, this option is disabled.
JDK-8230291: CDS Behavior Change With Non-existent Files During Archive Creation
In JDK 14, CDS runtime classpath validation is now more forgiving when dealing with files in
the classpath that do not exist.
At CDS archive dump time, all non-existent elements in the classpath are automatically
stripped. For example, if the command is:
java -cp nosuchfile.jar:hello.jar -Xshare:dump \
-XX:SharedClassListFile=hello.classlist \ -XX:SharedArchiveFile=hello.jsa
after removing the non-existing elements, the classpath recorded in `hello.jsa` becomes
`hello.jar`.
Also, at run time, when the CDS archive is loaded, all non-existent elements in the classpath
are ignored. With the previous example, all of the following commands will successfully load
the archive:
(1) ``` java -cp nosuchfile.jar:hello.jar -Xshare:on \
-XX:SharedArchiveFile=hello.jsa \ Hello ``` (2) ``` java -cp hello.jar
-Xshare:on \ -XX:SharedArchiveFile=hello.jsa \ Hello ``` (3) ``` java
-cp alsonosuchfile.jar:hello.jar -Xshare:on \ -XX:SharedArchiveFile=hello.jsa \
Hello ```
In JDK 13 and earlier, only (1) is allowed while (2) and (3) would trigger an error.
JDK-8227417: Added -XX:+AdjustStackSizeForTLS Flag
The `glibc` library allocates some thread-local storage (TLS) in the stack of a newly created
thread, leaving less stack than requested for the thread to do its work. This is particularly
a problem for threads with small stack sizes. It is an inherited issue from a well-known
`glibc` problem, 'Program with large TLS segments fail' [0] and has been observed in Java
applications. In one of the reported JVM failure instances, the issue manifests as a
`StackOverflowError` on the process reaper thread, which has a small stack size. The
`java.lang.Thread` constructor enables users to specify the stack size for a new thread. The
created thread may encounter the TLS problem when the specified size is too small to
accommodate the on-stack TLS blocks.
In JDK 8, a system property, `jdk.lang.processReaperUseDefaultStackSize`, was introduced to
address the TLS issue only for reaper threads. Setting the property gives a bigger stack size
to the reaper threads.
To address the issue for all threads, a general purpose workaround was implemented in Java
which adjusts thread stack size for TLS. It can be enabled by using the
`AdjustStackSizeForTLS` command-line option:
` -XX:+AdjustStackSizeForTLS`
When creating a new thread, if `AdjustStackSizeForTLS` is true, the static TLS area size is
added to the user requested stack size. `AdjustStackSizeForTLS` is disabled by default.
Reference: [0] [Bug 11787 - Program with large TLS segments
fail](https://sourceware.org/bugzilla/show_bug.cgi?id=11787)
JDK-8234771: Thread Interrupt State Is Always Available
The specification for `java.lang.Thread::interrupt` allows for an implementation to only track
the interrupt state for live threads, and previously this is what occurred. As of this
release, the interrupt state of a `Thread` is always available, and if you interrupt a thread
`t` before it is started, or after it has terminated, the query `t.isInterrupted()` will
return true.
JDK-8234223: Detailed Message in NullPointerExceptions
A new option is available to provide more helpful `NullPointerException` messages:
-XX:+ShowCodeDetailsInExceptionMessages
If the option is set, on encountering a null pointer, the JVM analyzes the program to
determine which reference was `null` and then provides the details as part of
`NullPointerException.getMessage()`. In addition to the exception message, the method,
filename, and line number are also returned.
By default, this option is disabled.
JDK-8230291: CDS Behavior Change With Non-existent Files During Archive Creation
In JDK 14, CDS runtime classpath validation is now more forgiving when dealing with files in
the classpath that do not exist.
At CDS archive dump time, all non-existent elements in the classpath are automatically
stripped. For example, if the command is:
java -cp nosuchfile.jar:hello.jar -Xshare:dump \
-XX:SharedClassListFile=hello.classlist \ -XX:SharedArchiveFile=hello.jsa
after removing the non-existing elements, the classpath recorded in `hello.jsa` becomes
`hello.jar`.
Also, at run time, when the CDS archive is loaded, all non-existent elements in the classpath
are ignored. With the previous example, all of the following commands will successfully load
the archive:
(1) ``` java -cp nosuchfile.jar:hello.jar -Xshare:on \
-XX:SharedArchiveFile=hello.jsa \ Hello ``` (2) ``` java -cp hello.jar
-Xshare:on \ -XX:SharedArchiveFile=hello.jsa \ Hello ``` (3) ``` java
-cp alsonosuchfile.jar:hello.jar -Xshare:on \ -XX:SharedArchiveFile=hello.jsa \
Hello ```
In JDK 13 and earlier, only (1) is allowed while (2) and (3) would trigger an error.
JDK-8227417: Added -XX:+AdjustStackSizeForTLS Flag
The `glibc` library allocates some thread-local storage (TLS) in the stack of a newly created
thread, leaving less stack than requested for the thread to do its work. This is particularly
a problem for threads with small stack sizes. It is an inherited issue from a well-known
`glibc` problem, 'Program with large TLS segments fail' [0] and has been observed in Java
applications. In one of the reported JVM failure instances, the issue manifests as a
`StackOverflowError` on the process reaper thread, which has a small stack size. The
`java.lang.Thread` constructor enables users to specify the stack size for a new thread. The
created thread may encounter the TLS problem when the specified size is too small to
accommodate the on-stack TLS blocks.
In JDK 8, a system property, `jdk.lang.processReaperUseDefaultStackSize`, was introduced to
address the TLS issue only for reaper threads. Setting the property gives a bigger stack size
to the reaper threads.
To address the issue for all threads, a general purpose workaround was implemented in Java
which adjusts thread stack size for TLS. It can be enabled by using the
`AdjustStackSizeForTLS` command-line option:
` -XX:+AdjustStackSizeForTLS`
When creating a new thread, if `AdjustStackSizeForTLS` is true, the static TLS area size is
added to the user requested stack size. `AdjustStackSizeForTLS` is disabled by default.
Reference: [0] [Bug 11787 - Program with large TLS segments
fail](https://sourceware.org/bugzilla/show_bug.cgi?id=11787)
JDK-8234771: Thread Interrupt State Is Always Available
The specification for `java.lang.Thread::interrupt` allows for an implementation to only track
the interrupt state for live threads, and previously this is what occurred. As of this
release, the interrupt state of a `Thread` is always available, and if you interrupt a thread
`t` before it is started, or after it has terminated, the query `t.isInterrupted()` will
return true.
JDK-8234223: Detailed Message in NullPointerExceptions
A new option is available to provide more helpful `NullPointerException` messages:
-XX:+ShowCodeDetailsInExceptionMessages
If the option is set, on encountering a null pointer, the JVM analyzes the program to
determine which reference was `null` and then provides the details as part of
`NullPointerException.getMessage()`. In addition to the exception message, the method,
filename, and line number are also returned.
By default, this option is disabled.
JDK-8230291: CDS Behavior Change With Non-existent Files During Archive Creation
In JDK 14, CDS runtime classpath validation is now more forgiving when dealing with files in
the classpath that do not exist.
At CDS archive dump time, all non-existent elements in the classpath are automatically
stripped. For example, if the command is:
java -cp nosuchfile.jar:hello.jar -Xshare:dump \
-XX:SharedClassListFile=hello.classlist \ -XX:SharedArchiveFile=hello.jsa
after removing the non-existing elements, the classpath recorded in `hello.jsa` becomes
`hello.jar`.
Also, at run time, when the CDS archive is loaded, all non-existent elements in the classpath
are ignored. With the previous example, all of the following commands will successfully load
the archive:
(1) ``` java -cp nosuchfile.jar:hello.jar -Xshare:on \
-XX:SharedArchiveFile=hello.jsa \ Hello ``` (2) ``` java -cp hello.jar
-Xshare:on \ -XX:SharedArchiveFile=hello.jsa \ Hello ``` (3) ``` java
-cp alsonosuchfile.jar:hello.jar -Xshare:on \ -XX:SharedArchiveFile=hello.jsa \
Hello ```
In JDK 13 and earlier, only (1) is allowed while (2) and (3) would trigger an error.
security-libs/java.security:
JDK-8234215: Added LuxTrust Global Root 2 Certificate
The following root certificate has been added to the cacerts truststore: ``` + LuxTrust +
luxtrustglobalroot2ca
DN: CN=LuxTrust Global Root 2, O=LuxTrust S.A., C=LU ```
JDK-8234774: Added 4 Amazon Root CA Certificates
The following root certificates have been added to the cacerts truststore: ``` + Amazon +
amazonrootca1 DN: CN=Amazon Root CA 1, O=Amazon, C=US
+ amazonrootca2 DN: CN=Amazon Root CA 2, O=Amazon, C=US
+ amazonrootca3 DN: CN=Amazon Root CA 3, O=Amazon, C=US
+ amazonrootca4 DN: CN=Amazon Root CA 4, O=Amazon, C=US ```
JDK-8236730: Weak Named Curves in TLS, CertPath, and Signed JAR Disabled by Default
Weak named curves are disabled by default by adding them to the following `disabledAlgorithms`
security properties: `jdk.tls.disabledAlgorithms`, `jdk.certpath.disabledAlgorithms`, and
`jdk.jar.disabledAlgorithms`. The named curves are listed below.
With 47 weak named curves to be disabled, adding individual named curves to each
`disabledAlgorithms` property would be overwhelming. To relieve this, a new security property,
`jdk.disabled.namedCurves`, is implemented that can list the named curves common to all of the
`disabledAlgorithms` properties. To use the new property in the `disabledAlgorithms`
properties, precede the full property name with the keyword `include`. Users can still add
individual named curves to `disabledAlgorithms` properties separate from this new property.
No other properties can be included in the `disabledAlgorithms` properties.
To restore the named curves, remove the `include jdk.disabled.namedCurves` either from
specific or from all `disabledAlgorithms` security properties. To restore one or more curves,
remove the specific named curve(s) from the `jdk.disabled.namedCurves` property.
Curves that are disabled through `jdk.disabled.namedCurves` include the following: secp112r1,
secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1,
secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1,
sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1,
sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2,
X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1,
X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2,
X9.62 prime239v3, brainpoolP256r1, brainpoolP320r1, brainpoolP384r1, brainpoolP512r1
Curves that remain enabled are: secp256r1, secp384r1, secp521r1, X25519, X448
JDK-8228664: Removed Deprecated java.security.acl APIs
The deprecated `java.security.acl` APIs have been removed. This includes the following classes
in that package: `Acl`, `AclEntry`, `AclNotFoundException`, `Group`, `LastOwnerException`,
`NotOwnerException`, `Owner`, and `Permission`.
JDK-8234207: Removal of the Default keytool -keyalg Value
The default key algorithm for the `keytool -genkeypair` and `keytool -genseckey` commands has
been removed. You must now specify the key algorithm by including the `-keyalg` option when
using the `-genkeypair` or `-genseckey` commands. If the `-keyalg` option is not specified,
the `keytool` will terminate with the error message: "The -keyalg option must be specified".
JDK-8234215: Added LuxTrust Global Root 2 Certificate
The following root certificate has been added to the cacerts truststore: ``` + LuxTrust +
luxtrustglobalroot2ca
DN: CN=LuxTrust Global Root 2, O=LuxTrust S.A., C=LU ```
JDK-8234774: Added 4 Amazon Root CA Certificates
The following root certificates have been added to the cacerts truststore: ``` + Amazon +
amazonrootca1 DN: CN=Amazon Root CA 1, O=Amazon, C=US
+ amazonrootca2 DN: CN=Amazon Root CA 2, O=Amazon, C=US
+ amazonrootca3 DN: CN=Amazon Root CA 3, O=Amazon, C=US
+ amazonrootca4 DN: CN=Amazon Root CA 4, O=Amazon, C=US ```
JDK-8236730: Weak Named Curves in TLS, CertPath, and Signed JAR Disabled by Default
Weak named curves are disabled by default by adding them to the following `disabledAlgorithms`
security properties: `jdk.tls.disabledAlgorithms`, `jdk.certpath.disabledAlgorithms`, and
`jdk.jar.disabledAlgorithms`. The named curves are listed below.
With 47 weak named curves to be disabled, adding individual named curves to each
`disabledAlgorithms` property would be overwhelming. To relieve this, a new security property,
`jdk.disabled.namedCurves`, is implemented that can list the named curves common to all of the
`disabledAlgorithms` properties. To use the new property in the `disabledAlgorithms`
properties, precede the full property name with the keyword `include`. Users can still add
individual named curves to `disabledAlgorithms` properties separate from this new property.
No other properties can be included in the `disabledAlgorithms` properties.
To restore the named curves, remove the `include jdk.disabled.namedCurves` either from
specific or from all `disabledAlgorithms` security properties. To restore one or more curves,
remove the specific named curve(s) from the `jdk.disabled.namedCurves` property.
Curves that are disabled through `jdk.disabled.namedCurves` include the following: secp112r1,
secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1,
secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1,
sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1,
sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2,
X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1,
X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2,
X9.62 prime239v3, brainpoolP256r1, brainpoolP320r1, brainpoolP384r1, brainpoolP512r1
Curves that remain enabled are: secp256r1, secp384r1, secp521r1, X25519, X448
JDK-8228664: Removed Deprecated java.security.acl APIs
The deprecated `java.security.acl` APIs have been removed. This includes the following classes
in that package: `Acl`, `AclEntry`, `AclNotFoundException`, `Group`, `LastOwnerException`,
`NotOwnerException`, `Owner`, and `Permission`.
JDK-8234207: Removal of the Default keytool -keyalg Value
The default key algorithm for the `keytool -genkeypair` and `keytool -genseckey` commands has
been removed. You must now specify the key algorithm by including the `-keyalg` option when
using the `-genkeypair` or `-genseckey` commands. If the `-keyalg` option is not specified,
the `keytool` will terminate with the error message: "The -keyalg option must be specified".
JDK-8234215: Added LuxTrust Global Root 2 Certificate
The following root certificate has been added to the cacerts truststore: ``` + LuxTrust +
luxtrustglobalroot2ca
DN: CN=LuxTrust Global Root 2, O=LuxTrust S.A., C=LU ```
JDK-8234774: Added 4 Amazon Root CA Certificates
The following root certificates have been added to the cacerts truststore: ``` + Amazon +
amazonrootca1 DN: CN=Amazon Root CA 1, O=Amazon, C=US
+ amazonrootca2 DN: CN=Amazon Root CA 2, O=Amazon, C=US
+ amazonrootca3 DN: CN=Amazon Root CA 3, O=Amazon, C=US
+ amazonrootca4 DN: CN=Amazon Root CA 4, O=Amazon, C=US ```
JDK-8236730: Weak Named Curves in TLS, CertPath, and Signed JAR Disabled by Default
Weak named curves are disabled by default by adding them to the following `disabledAlgorithms`
security properties: `jdk.tls.disabledAlgorithms`, `jdk.certpath.disabledAlgorithms`, and
`jdk.jar.disabledAlgorithms`. The named curves are listed below.
With 47 weak named curves to be disabled, adding individual named curves to each
`disabledAlgorithms` property would be overwhelming. To relieve this, a new security property,
`jdk.disabled.namedCurves`, is implemented that can list the named curves common to all of the
`disabledAlgorithms` properties. To use the new property in the `disabledAlgorithms`
properties, precede the full property name with the keyword `include`. Users can still add
individual named curves to `disabledAlgorithms` properties separate from this new property.
No other properties can be included in the `disabledAlgorithms` properties.
To restore the named curves, remove the `include jdk.disabled.namedCurves` either from
specific or from all `disabledAlgorithms` security properties. To restore one or more curves,
remove the specific named curve(s) from the `jdk.disabled.namedCurves` property.
Curves that are disabled through `jdk.disabled.namedCurves` include the following: secp112r1,
secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1,
secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1,
sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1,
sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2,
X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1,
X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2,
X9.62 prime239v3, brainpoolP256r1, brainpoolP320r1, brainpoolP384r1, brainpoolP512r1
Curves that remain enabled are: secp256r1, secp384r1, secp521r1, X25519, X448
JDK-8228664: Removed Deprecated java.security.acl APIs
The deprecated `java.security.acl` APIs have been removed. This includes the following classes
in that package: `Acl`, `AclEntry`, `AclNotFoundException`, `Group`, `LastOwnerException`,
`NotOwnerException`, `Owner`, and `Permission`.
JDK-8234207: Removal of the Default keytool -keyalg Value
The default key algorithm for the `keytool -genkeypair` and `keytool -genseckey` commands has
been removed. You must now specify the key algorithm by including the `-keyalg` option when
using the `-genkeypair` or `-genseckey` commands. If the `-keyalg` option is not specified,
the `keytool` will terminate with the error message: "The -keyalg option must be specified".
JDK-8234215: Added LuxTrust Global Root 2 Certificate
The following root certificate has been added to the cacerts truststore: ``` + LuxTrust +
luxtrustglobalroot2ca
DN: CN=LuxTrust Global Root 2, O=LuxTrust S.A., C=LU ```
JDK-8234774: Added 4 Amazon Root CA Certificates
The following root certificates have been added to the cacerts truststore: ``` + Amazon +
amazonrootca1 DN: CN=Amazon Root CA 1, O=Amazon, C=US
+ amazonrootca2 DN: CN=Amazon Root CA 2, O=Amazon, C=US
+ amazonrootca3 DN: CN=Amazon Root CA 3, O=Amazon, C=US
+ amazonrootca4 DN: CN=Amazon Root CA 4, O=Amazon, C=US ```
JDK-8236730: Weak Named Curves in TLS, CertPath, and Signed JAR Disabled by Default
Weak named curves are disabled by default by adding them to the following `disabledAlgorithms`
security properties: `jdk.tls.disabledAlgorithms`, `jdk.certpath.disabledAlgorithms`, and
`jdk.jar.disabledAlgorithms`. The named curves are listed below.
With 47 weak named curves to be disabled, adding individual named curves to each
`disabledAlgorithms` property would be overwhelming. To relieve this, a new security property,
`jdk.disabled.namedCurves`, is implemented that can list the named curves common to all of the
`disabledAlgorithms` properties. To use the new property in the `disabledAlgorithms`
properties, precede the full property name with the keyword `include`. Users can still add
individual named curves to `disabledAlgorithms` properties separate from this new property.
No other properties can be included in the `disabledAlgorithms` properties.
To restore the named curves, remove the `include jdk.disabled.namedCurves` either from
specific or from all `disabledAlgorithms` security properties. To restore one or more curves,
remove the specific named curve(s) from the `jdk.disabled.namedCurves` property.
Curves that are disabled through `jdk.disabled.namedCurves` include the following: secp112r1,
secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1,
secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1,
sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1,
sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2,
X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1,
X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2,
X9.62 prime239v3, brainpoolP256r1, brainpoolP320r1, brainpoolP384r1, brainpoolP512r1
Curves that remain enabled are: secp256r1, secp384r1, secp521r1, X25519, X448
JDK-8228664: Removed Deprecated java.security.acl APIs
The deprecated `java.security.acl` APIs have been removed. This includes the following classes
in that package: `Acl`, `AclEntry`, `AclNotFoundException`, `Group`, `LastOwnerException`,
`NotOwnerException`, `Owner`, and `Permission`.
JDK-8234207: Removal of the Default keytool -keyalg Value
The default key algorithm for the `keytool -genkeypair` and `keytool -genseckey` commands has
been removed. You must now specify the key algorithm by including the `-keyalg` option when
using the `-genkeypair` or `-genseckey` commands. If the `-keyalg` option is not specified,
the `keytool` will terminate with the error message: "The -keyalg option must be specified".
JDK-8234215: Added LuxTrust Global Root 2 Certificate
The following root certificate has been added to the cacerts truststore: ``` + LuxTrust +
luxtrustglobalroot2ca
DN: CN=LuxTrust Global Root 2, O=LuxTrust S.A., C=LU ```
JDK-8234774: Added 4 Amazon Root CA Certificates
The following root certificates have been added to the cacerts truststore: ``` + Amazon +
amazonrootca1 DN: CN=Amazon Root CA 1, O=Amazon, C=US
+ amazonrootca2 DN: CN=Amazon Root CA 2, O=Amazon, C=US
+ amazonrootca3 DN: CN=Amazon Root CA 3, O=Amazon, C=US
+ amazonrootca4 DN: CN=Amazon Root CA 4, O=Amazon, C=US ```
JDK-8236730: Weak Named Curves in TLS, CertPath, and Signed JAR Disabled by Default
Weak named curves are disabled by default by adding them to the following `disabledAlgorithms`
security properties: `jdk.tls.disabledAlgorithms`, `jdk.certpath.disabledAlgorithms`, and
`jdk.jar.disabledAlgorithms`. The named curves are listed below.
With 47 weak named curves to be disabled, adding individual named curves to each
`disabledAlgorithms` property would be overwhelming. To relieve this, a new security property,
`jdk.disabled.namedCurves`, is implemented that can list the named curves common to all of the
`disabledAlgorithms` properties. To use the new property in the `disabledAlgorithms`
properties, precede the full property name with the keyword `include`. Users can still add
individual named curves to `disabledAlgorithms` properties separate from this new property.
No other properties can be included in the `disabledAlgorithms` properties.
To restore the named curves, remove the `include jdk.disabled.namedCurves` either from
specific or from all `disabledAlgorithms` security properties. To restore one or more curves,
remove the specific named curve(s) from the `jdk.disabled.namedCurves` property.
Curves that are disabled through `jdk.disabled.namedCurves` include the following: secp112r1,
secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1,
secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1,
sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1,
sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2,
X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1,
X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2,
X9.62 prime239v3, brainpoolP256r1, brainpoolP320r1, brainpoolP384r1, brainpoolP512r1
Curves that remain enabled are: secp256r1, secp384r1, secp521r1, X25519, X448
JDK-8228664: Removed Deprecated java.security.acl APIs
The deprecated `java.security.acl` APIs have been removed. This includes the following classes
in that package: `Acl`, `AclEntry`, `AclNotFoundException`, `Group`, `LastOwnerException`,
`NotOwnerException`, `Owner`, and `Permission`.
JDK-8234207: Removal of the Default keytool -keyalg Value
The default key algorithm for the `keytool -genkeypair` and `keytool -genseckey` commands has
been removed. You must now specify the key algorithm by including the `-keyalg` option when
using the `-genkeypair` or `-genseckey` commands. If the `-keyalg` option is not specified,
the `keytool` will terminate with the error message: "The -keyalg option must be specified".
xml/jaxp:
JDK-8230936: New Method to SAX ContentHandler for Handling XML Declaration
A new method `declaration` has been added to `SAX ContentHandler` to receive notification of
the XML declaration. By implementing this method, applications can receive the values of
version, encoding, and standalone attributes exactly as declared in the input document.
tools/jar:
JDK-8235712: JEP 367: Remove the Pack200 Tools and API
The `pack200` and `unpack200` tools, added in JDK 5.0, have been removed. The class
`java.util.jar.Pack200` and the interfaces `java.util.jar.Pack200.Packer` and
`java.util.jar.Pack200.Unpacker` have also been removed. These tools and API were deprecated
for removal in Java SE 11 with the express intent to remove them in a future release. In
addition, in the `jar` tool, the `n` sub-option to `jar c` has been removed. See [JEP 367:
Remove the Pack200 Tools and API](https://openjdk.java.net/jeps/367) for more information.
core-libs/java.lang.invoke:
JDK-8230819: MethodType::fromMethodDescriptorString Requires "getClassLoader" Permission
`MethodType::fromMethodDescriptorString` has been changed in this release. When a security
manager is present and the `loader` parameter is null, it performs a
RuntimePermission("getClassLoader") security permission check. This check ensures that access
to the system class loader is permitted.
Existing code that calls `MethodType.fromMethodDescriptorString(desc, null)` might get a
`SecurityException` if access to the system class loader is denied. The security policy must
be configured to grant the permission. Applications running without a security manager or
with a non-null loader are not affected by this change.
JDK-8238458: Lookup::in Throws IllegalArgumentException If requestedLookupClass Is a Primitive Type or an Array Class
`java.lang.invoke.MethodHandles.Lookup::in` method throws `IllegalArgumentException` if the
given `requestedLookupClass` is a primitive type, void, or an array class. A `Lookup` object
never intends to allow a lookup class of primitive type, void, or array class. Consequently,
the specification of `Lookup::in` has been fixed in Java SE 14.
JDK-8228624: MethodHandles::privateLookupIn Requires PRIVATE Lookup Mode
`MethodHandles::privateLookupIn` has been changed. In this release, the caller `Lookup` must
have both `PRIVATE` and `MODULE` access because an application intending to share intra-module
access using `MODULE` alone will inadvertently also share deep reflection to its own module.
In addition, if a `Lookup` object is created by `Lookup::in` or
`MethodHandles::privateLookupIn` teleporting from one module to another module, the `MODULE`
mode is dropped. In other words, `MethodHandles::privateLookupIn` requires that the caller
lookup object must be created by a member from the caller's module and not be produced by
cross-module teleporting.
For example, a lookup object `L` created by calling `MethodHandles.privateLookupIn(C.class,
caller)` (where C is a class in module M1, and the caller's lookup class is in module M0) can
access public members of public class D in module M2 if: - M0 and M1 read M2, and - D is in
a package exported from M2 to at least both M0 and M1.
If D in M2 is accessible to M0 but not to M1, lookup object `L` will fail to lookup members in
D in this release, but would have succeeded in previous releases.
JDK-8233527: Update Lookup::hasPrivateAccess and Lookup::defineClass spec w.r.t. full power lookup
Lookup::hasPrivateAccess intends to return true for "full-power lookup", i.e. a Lookup
produced by the MethodHandles::lookup factory method where the caller class is the lookup
class.
With JDK-8173978, MODULE bit indicates if this lookup object is created by a member in the
same module as the lookup class. MethodHandles::privateLookupIn can produce a Lookup with
MODULE bit dropped if teleporting from another module.
Lookup::hasPrivateAccess should be updated to return true if this lookup has both PRIVATE and
MODULE access.
JDK-8230819: MethodType::fromMethodDescriptorString Requires "getClassLoader" Permission
`MethodType::fromMethodDescriptorString` has been changed in this release. When a security
manager is present and the `loader` parameter is null, it performs a
RuntimePermission("getClassLoader") security permission check. This check ensures that access
to the system class loader is permitted.
Existing code that calls `MethodType.fromMethodDescriptorString(desc, null)` might get a
`SecurityException` if access to the system class loader is denied. The security policy must
be configured to grant the permission. Applications running without a security manager or
with a non-null loader are not affected by this change.
JDK-8238458: Lookup::in Throws IllegalArgumentException If requestedLookupClass Is a Primitive Type or an Array Class
`java.lang.invoke.MethodHandles.Lookup::in` method throws `IllegalArgumentException` if the
given `requestedLookupClass` is a primitive type, void, or an array class. A `Lookup` object
never intends to allow a lookup class of primitive type, void, or array class. Consequently,
the specification of `Lookup::in` has been fixed in Java SE 14.
JDK-8228624: MethodHandles::privateLookupIn Requires PRIVATE Lookup Mode
`MethodHandles::privateLookupIn` has been changed. In this release, the caller `Lookup` must
have both `PRIVATE` and `MODULE` access because an application intending to share intra-module
access using `MODULE` alone will inadvertently also share deep reflection to its own module.
In addition, if a `Lookup` object is created by `Lookup::in` or
`MethodHandles::privateLookupIn` teleporting from one module to another module, the `MODULE`
mode is dropped. In other words, `MethodHandles::privateLookupIn` requires that the caller
lookup object must be created by a member from the caller's module and not be produced by
cross-module teleporting.
For example, a lookup object `L` created by calling `MethodHandles.privateLookupIn(C.class,
caller)` (where C is a class in module M1, and the caller's lookup class is in module M0) can
access public members of public class D in module M2 if: - M0 and M1 read M2, and - D is in
a package exported from M2 to at least both M0 and M1.
If D in M2 is accessible to M0 but not to M1, lookup object `L` will fail to lookup members in
D in this release, but would have succeeded in previous releases.
JDK-8233527: Update Lookup::hasPrivateAccess and Lookup::defineClass spec w.r.t. full power lookup
Lookup::hasPrivateAccess intends to return true for "full-power lookup", i.e. a Lookup
produced by the MethodHandles::lookup factory method where the caller class is the lookup
class.
With JDK-8173978, MODULE bit indicates if this lookup object is created by a member in the
same module as the lookup class. MethodHandles::privateLookupIn can produce a Lookup with
MODULE bit dropped if teleporting from another module.
Lookup::hasPrivateAccess should be updated to return true if this lookup has both PRIVATE and
MODULE access.
JDK-8230819: MethodType::fromMethodDescriptorString Requires "getClassLoader" Permission
`MethodType::fromMethodDescriptorString` has been changed in this release. When a security
manager is present and the `loader` parameter is null, it performs a
RuntimePermission("getClassLoader") security permission check. This check ensures that access
to the system class loader is permitted.
Existing code that calls `MethodType.fromMethodDescriptorString(desc, null)` might get a
`SecurityException` if access to the system class loader is denied. The security policy must
be configured to grant the permission. Applications running without a security manager or
with a non-null loader are not affected by this change.
JDK-8238458: Lookup::in Throws IllegalArgumentException If requestedLookupClass Is a Primitive Type or an Array Class
`java.lang.invoke.MethodHandles.Lookup::in` method throws `IllegalArgumentException` if the
given `requestedLookupClass` is a primitive type, void, or an array class. A `Lookup` object
never intends to allow a lookup class of primitive type, void, or array class. Consequently,
the specification of `Lookup::in` has been fixed in Java SE 14.
JDK-8228624: MethodHandles::privateLookupIn Requires PRIVATE Lookup Mode
`MethodHandles::privateLookupIn` has been changed. In this release, the caller `Lookup` must
have both `PRIVATE` and `MODULE` access because an application intending to share intra-module
access using `MODULE` alone will inadvertently also share deep reflection to its own module.
In addition, if a `Lookup` object is created by `Lookup::in` or
`MethodHandles::privateLookupIn` teleporting from one module to another module, the `MODULE`
mode is dropped. In other words, `MethodHandles::privateLookupIn` requires that the caller
lookup object must be created by a member from the caller's module and not be produced by
cross-module teleporting.
For example, a lookup object `L` created by calling `MethodHandles.privateLookupIn(C.class,
caller)` (where C is a class in module M1, and the caller's lookup class is in module M0) can
access public members of public class D in module M2 if: - M0 and M1 read M2, and - D is in
a package exported from M2 to at least both M0 and M1.
If D in M2 is accessible to M0 but not to M1, lookup object `L` will fail to lookup members in
D in this release, but would have succeeded in previous releases.
JDK-8233527: Update Lookup::hasPrivateAccess and Lookup::defineClass spec w.r.t. full power lookup
Lookup::hasPrivateAccess intends to return true for "full-power lookup", i.e. a Lookup
produced by the MethodHandles::lookup factory method where the caller class is the lookup
class.
With JDK-8173978, MODULE bit indicates if this lookup object is created by a member in the
same module as the lookup class. MethodHandles::privateLookupIn can produce a Lookup with
MODULE bit dropped if teleporting from another module.
Lookup::hasPrivateAccess should be updated to return true if this lookup has both PRIVATE and
MODULE access.
security-libs/javax.xml.crypto:
JDK-8239467: Apache Santuario Library Updated to Version 2.1.4
The Apache Santuario library has been upgraded to version 2.1.4. As a result, a new system
property `com.sun.org.apache.xml.internal.security.parser.pool-size` has been introduced.
This new system property sets the pool size of the internal `DocumentBuilder` cache used when
processing XML Signatures. The function is equivalent to the
`org.apache.xml.security.parser.pool-size` system property used in Apache Santuario and has
the same default value of 20.
core-libs/javax.lang.model:
JDK-8238893: ExecutableElement.getReceiverType Changed to Return NOTYPE Rather Than null
The specification for `ExecutableElement.getReceiverType` requires it to return `NOTYPE` when
a receiver type is not defined. The implementation has been changed to return `NOTYPE` in this
case rather than null.
core-libs/java.text:
JDK-8229146: Accounting Currency Format Support
Currency format instances with accounting style, in which the amount is formatted in
parentheses in some locales, can be obtained by calling
`NumberFormat.getCurrencyInstance(Locale)` with the "u-cf-account" Unicode locale extension.
For example in `Locale.US`, it will format to "`($3.27)`" instead of "`-$3.27`". Refer to
[CLDR's accounting currency format
style](https://www.unicode.org/reports/tr35/tr35-33/tr35-numbers.html#Currency_Formats) for
additional information.
core-libs/javax.naming:
JDK-8231406: DnsClient TCP Socket Timeout
The semantics of the `com.sun.jndi.dns.timeout.initial` property of the JNDI DNS provider
implementation have been amended. The value of this timeout now uniformly applies to both UDP
and TCP queries. Previously it applied only to UDP queries.
core-libs/java.util.jar:
JDK-8232384: ZipFileInputStream::skip handling of negative values
When accessing a STORED entry within a Zip file using `ZipFileInputStream`, a negative value
may be specified in order to skip backwards within the STORED entry and a negative value is
returned indicating the number of bytes skipped backwards. If the specified value would move
beyond the beginning of the file, the position is set to the beginning of the file and a
negative value is returned indicating the number of bytes moved from the current position to
the beginning of the file.
When accessing a DEFLATED entry within a Zip file using `ZipFileInflaterInputStream` and a
negative value is specified to the skip method, an `IllegalArgumentException` will be thrown.
hotspot/compiler:
JDK-8228418: Turned Off AOT by Default and Changed Related Flags to Experimental
The default value of `UseAOT` has been changed from `enabled` to `disabled`, and the following
AOT support related flags have been changed to experimental:
- `UseAOT` - `PrintAOT` - `AOTLibrary`
security-libs/javax.net.ssl:
JDK-8242399: Stateless Resumption Enabled by Default for JSSE Server
Server-side JSSE now operates in stateless mode by default. As described in RFC 5077[1] for
TLS 1.2 and below, and RFC 8446[2] for TLS 1.3, the TLS server sends internal session
information in the form of an encrypted session ticket to a client that supports stateless.
That session ticket is presented to the server during the TLS handshake to resume the session.
This should improve the performance and memory usage of the TLS server under large workloads
as the session cache will seldom be used. Applications that depend on SSLSession to list
sessions cached will not find that information in stateless mode.
If stateless needs to be turned off, use the System property
`jdk.tls.server.enableSessionTicketExtension`. Using
`-Djdk.tls.server.enableSessionTicketExtension=false` on the command-line will turn off
stateless and return the JSSE server to using the session cache.
[1]: https://tools.ietf.org/html/rfc5077 [2]: https://tools.ietf.org/html/rfc8446
JDK-8235639: Removed SSLv2Hello and SSLv3 From Default Enabled TLS Protocols
SSLv2Hello and SSLv3 have been removed from the default enabled TLS protocols.
After this update, if SSLv3 is removed from the `jdk.tls.disabledAlgorithms` security
property, the `SSLSocket.getEnabledProtocols()`, `SSLServerSocket.getEnabledProtocols()`,
`SSLEngine.getEnabledProtocols()` and `SSLParameters.getProtocols()` APIs will return
"TLSv1.3, TLSv1.2, TLSv1.1, TLSv1". "SSLv3" will not be returned in this list.
If a client or server still needs to use the SSLv3 protocol they can do so by enabling it
through the `jdk.tls.client.protocols` or `jdk.tls.server.protocols` system properties or with
the `SSLSocket.setEnabledProtocols()`, `SSLServerSocket.setEnabledProtocols()` and
`SSLEngine.setEnabledProtocols()` APIs.
JDK-8242399: Stateless Resumption Enabled by Default for JSSE Server
Server-side JSSE now operates in stateless mode by default. As described in RFC 5077[1] for
TLS 1.2 and below, and RFC 8446[2] for TLS 1.3, the TLS server sends internal session
information in the form of an encrypted session ticket to a client that supports stateless.
That session ticket is presented to the server during the TLS handshake to resume the session.
This should improve the performance and memory usage of the TLS server under large workloads
as the session cache will seldom be used. Applications that depend on SSLSession to list
sessions cached will not find that information in stateless mode.
If stateless needs to be turned off, use the System property
`jdk.tls.server.enableSessionTicketExtension`. Using
`-Djdk.tls.server.enableSessionTicketExtension=false` on the command-line will turn off
stateless and return the JSSE server to using the session cache.
[1]: https://tools.ietf.org/html/rfc5077 [2]: https://tools.ietf.org/html/rfc8446
JDK-8235639: Removed SSLv2Hello and SSLv3 From Default Enabled TLS Protocols
SSLv2Hello and SSLv3 have been removed from the default enabled TLS protocols.
After this update, if SSLv3 is removed from the `jdk.tls.disabledAlgorithms` security
property, the `SSLSocket.getEnabledProtocols()`, `SSLServerSocket.getEnabledProtocols()`,
`SSLEngine.getEnabledProtocols()` and `SSLParameters.getProtocols()` APIs will return
"TLSv1.3, TLSv1.2, TLSv1.1, TLSv1". "SSLv3" will not be returned in this list.
If a client or server still needs to use the SSLv3 protocol they can do so by enabling it
through the `jdk.tls.client.protocols` or `jdk.tls.server.protocols` system properties or with
the `SSLSocket.setEnabledProtocols()`, `SSLServerSocket.setEnabledProtocols()` and
`SSLEngine.setEnabledProtocols()` APIs.
security-libs/javax.crypto:
JDK-8235768: Deprecated the OracleUcrypto JCE Provider for Removal
The OracleUcrypto JCE Provider and its containing module `jdk.crypto.ucrypto` have been
deprecated and are subject to removal in a future version of the JDK. See [JEP
362](https://openjdk.java.net/jeps/362) for more information.
JDK-8229043: SunJCE Provider Throws NoSuchAlgorithmException for AES/GCM/PKCS5Padding
Prior to this release, the SunJCE provider incorrectly returned a `Cipher` instance for the
"AES/GCM/NoPadding" transformation when a caller requested "AES/GCM/PKCS5Padding". The SunJCE
provider now throws `NoSuchAlgorithmException` when "AES/GCM/PKCS5Padding" is requested. If
you are impacted by this issue, the workaround is to use "AES/GCM/NoPadding" instead.
JDK-8235666: Deprecated the Legacy Elliptic Curves for Removal
The following named elliptic curves supported by the `SunEC` provider have been deprecated:
brainpoolP256r1, brainpoolP320r1, brainpoolP384r1, brainpoolP512r1, secp112r1, secp112r2,
secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1,
secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1,
sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1,
sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62
c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62
c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62
prime239v3
The implementations of these curves are targeted to be removed in a subsequent JDK release. A
small number of them may be replaced with a more modern implementation.
JDK-8234609: Protected javax.crypto.Cipher Constructor Throws IAE for Non-null Invalid Arguments
The protected constructor of `javax.crypto.Cipher` has been changed to throw
`IllegalArgumentException` instead of `NullPointerException` if the supplied arguments are
deemed invalid for constructing the `Cipher` object. If the provider argument is null, the
constructor will throw `NullPointerException` as before. Both exceptions are now documented in
the javadoc specification of the protected constructor.
JDK-8235768: Deprecated the OracleUcrypto JCE Provider for Removal
The OracleUcrypto JCE Provider and its containing module `jdk.crypto.ucrypto` have been
deprecated and are subject to removal in a future version of the JDK. See [JEP
362](https://openjdk.java.net/jeps/362) for more information.
JDK-8229043: SunJCE Provider Throws NoSuchAlgorithmException for AES/GCM/PKCS5Padding
Prior to this release, the SunJCE provider incorrectly returned a `Cipher` instance for the
"AES/GCM/NoPadding" transformation when a caller requested "AES/GCM/PKCS5Padding". The SunJCE
provider now throws `NoSuchAlgorithmException` when "AES/GCM/PKCS5Padding" is requested. If
you are impacted by this issue, the workaround is to use "AES/GCM/NoPadding" instead.
JDK-8235666: Deprecated the Legacy Elliptic Curves for Removal
The following named elliptic curves supported by the `SunEC` provider have been deprecated:
brainpoolP256r1, brainpoolP320r1, brainpoolP384r1, brainpoolP512r1, secp112r1, secp112r2,
secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1,
secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1,
sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1,
sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62
c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62
c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62
prime239v3
The implementations of these curves are targeted to be removed in a subsequent JDK release. A
small number of them may be replaced with a more modern implementation.
JDK-8234609: Protected javax.crypto.Cipher Constructor Throws IAE for Non-null Invalid Arguments
The protected constructor of `javax.crypto.Cipher` has been changed to throw
`IllegalArgumentException` instead of `NullPointerException` if the supplied arguments are
deemed invalid for constructing the `Cipher` object. If the provider argument is null, the
constructor will throw `NullPointerException` as before. Both exceptions are now documented in
the javadoc specification of the protected constructor.
JDK-8235768: Deprecated the OracleUcrypto JCE Provider for Removal
The OracleUcrypto JCE Provider and its containing module `jdk.crypto.ucrypto` have been
deprecated and are subject to removal in a future version of the JDK. See [JEP
362](https://openjdk.java.net/jeps/362) for more information.
JDK-8229043: SunJCE Provider Throws NoSuchAlgorithmException for AES/GCM/PKCS5Padding
Prior to this release, the SunJCE provider incorrectly returned a `Cipher` instance for the
"AES/GCM/NoPadding" transformation when a caller requested "AES/GCM/PKCS5Padding". The SunJCE
provider now throws `NoSuchAlgorithmException` when "AES/GCM/PKCS5Padding" is requested. If
you are impacted by this issue, the workaround is to use "AES/GCM/NoPadding" instead.
JDK-8235666: Deprecated the Legacy Elliptic Curves for Removal
The following named elliptic curves supported by the `SunEC` provider have been deprecated:
brainpoolP256r1, brainpoolP320r1, brainpoolP384r1, brainpoolP512r1, secp112r1, secp112r2,
secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1,
secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1,
sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1,
sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62
c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62
c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62
prime239v3
The implementations of these curves are targeted to be removed in a subsequent JDK release. A
small number of them may be replaced with a more modern implementation.
JDK-8234609: Protected javax.crypto.Cipher Constructor Throws IAE for Non-null Invalid Arguments
The protected constructor of `javax.crypto.Cipher` has been changed to throw
`IllegalArgumentException` instead of `NullPointerException` if the supplied arguments are
deemed invalid for constructing the `Cipher` object. If the provider argument is null, the
constructor will throw `NullPointerException` as before. Both exceptions are now documented in
the javadoc specification of the protected constructor.
JDK-8235768: Deprecated the OracleUcrypto JCE Provider for Removal
The OracleUcrypto JCE Provider and its containing module `jdk.crypto.ucrypto` have been
deprecated and are subject to removal in a future version of the JDK. See [JEP
362](https://openjdk.java.net/jeps/362) for more information.
JDK-8229043: SunJCE Provider Throws NoSuchAlgorithmException for AES/GCM/PKCS5Padding
Prior to this release, the SunJCE provider incorrectly returned a `Cipher` instance for the
"AES/GCM/NoPadding" transformation when a caller requested "AES/GCM/PKCS5Padding". The SunJCE
provider now throws `NoSuchAlgorithmException` when "AES/GCM/PKCS5Padding" is requested. If
you are impacted by this issue, the workaround is to use "AES/GCM/NoPadding" instead.
JDK-8235666: Deprecated the Legacy Elliptic Curves for Removal
The following named elliptic curves supported by the `SunEC` provider have been deprecated:
brainpoolP256r1, brainpoolP320r1, brainpoolP384r1, brainpoolP512r1, secp112r1, secp112r2,
secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1,
secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1,
sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1,
sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62
c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62
c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62
prime239v3
The implementations of these curves are targeted to be removed in a subsequent JDK release. A
small number of them may be replaced with a more modern implementation.
JDK-8234609: Protected javax.crypto.Cipher Constructor Throws IAE for Non-null Invalid Arguments
The protected constructor of `javax.crypto.Cipher` has been changed to throw
`IllegalArgumentException` instead of `NullPointerException` if the supplied arguments are
deemed invalid for constructing the `Cipher` object. If the provider argument is null, the
constructor will throw `NullPointerException` as before. Both exceptions are now documented in
the javadoc specification of the protected constructor.
core-libs/java.nio:
JDK-8231899: Zip File System Throws java.nio.file.NoSuchFileException When the File Does Not Exist and Is Not Being Created
The Zip File System has been updated to throw `java.nio.file.NoSuchFileException` (a
subclass of `IOException`), when `java.nio.file.FileSystems.newFileSystem` is used to create a
new file system; the specified Zip or JAR file does not exist, and the Zip provider property
`create` is not set to `true`.
JDK-8230045: Using the ZIP File System (zipfs) Provider to Update a ZIP or JAR File Containing Uncompressed Entries Might Corrupt the File
Using the ZIP File System (`zipfs`) to update a JAR or ZIP file might corrupt that file.
Corruption occurs only if the JAR or ZIP file contains a non-compressed entry. If the JAR or
ZIP file contains only compressed entries, as is typical, then no data corruption occurs.
As a workaround, users can use the `jar` tool or the `java.util.zip` API to update JAR or ZIP
files that contain non-compressed entries.
JDK-8240909: Clarify the Specification of ReadableByteChannel.read() and Related Methods
The specifications of the `DatagramChannel.receive()`, `FileChannel.read(ByteBuffer,long)`,
`ReadableByteChannel.read()`, and `ScatteringByteChannel.read()` methods have been updated in
this release to specify that an `IllegalArgumentException` is thrown if (any of) the buffer
parameter(s) is read-only. This change merely adjusts the specification to match existing long
term behavior.
JDK-8231881: DatagramChannel.disconnect Might Leave the Channel's Socket in an Unspecified State
The `DatagramChannel` implementation has been updated in this release so that the `disconnect`
method attempts to workaround Linux kernel behavior that reverts the local port to 0 after
dissolving the association. The issue arises when a `DatagramChannel` is initially bound to an
ephemeral port, connected (by calling its `connect` method), and then disconnected (by calling
its `disconnect` method). The workaround in the `DatagramChannel::disconnect` is to attempt to
re-bind the channel's socket to its original port. This usually succeeds, but if it fails, an
`IOException` is thrown. This workaround has been used in the `DatagramSocket` implementation
for several releases.
As part of this change, the `javadoc` for `DatagramChannel::disconnect` has been updated with
an API note to make it clear that an `IOException` might leave the channel's socket in an
unspecified state. The API note also strongly recommends that the channel be closed when the
`disconnect` fails.
JDK-8231899: Zip File System Throws java.nio.file.NoSuchFileException When the File Does Not Exist and Is Not Being Created
The Zip File System has been updated to throw `java.nio.file.NoSuchFileException` (a
subclass of `IOException`), when `java.nio.file.FileSystems.newFileSystem` is used to create a
new file system; the specified Zip or JAR file does not exist, and the Zip provider property
`create` is not set to `true`.
JDK-8230045: Using the ZIP File System (zipfs) Provider to Update a ZIP or JAR File Containing Uncompressed Entries Might Corrupt the File
Using the ZIP File System (`zipfs`) to update a JAR or ZIP file might corrupt that file.
Corruption occurs only if the JAR or ZIP file contains a non-compressed entry. If the JAR or
ZIP file contains only compressed entries, as is typical, then no data corruption occurs.
As a workaround, users can use the `jar` tool or the `java.util.zip` API to update JAR or ZIP
files that contain non-compressed entries.
JDK-8240909: Clarify the Specification of ReadableByteChannel.read() and Related Methods
The specifications of the `DatagramChannel.receive()`, `FileChannel.read(ByteBuffer,long)`,
`ReadableByteChannel.read()`, and `ScatteringByteChannel.read()` methods have been updated in
this release to specify that an `IllegalArgumentException` is thrown if (any of) the buffer
parameter(s) is read-only. This change merely adjusts the specification to match existing long
term behavior.
JDK-8231881: DatagramChannel.disconnect Might Leave the Channel's Socket in an Unspecified State
The `DatagramChannel` implementation has been updated in this release so that the `disconnect`
method attempts to workaround Linux kernel behavior that reverts the local port to 0 after
dissolving the association. The issue arises when a `DatagramChannel` is initially bound to an
ephemeral port, connected (by calling its `connect` method), and then disconnected (by calling
its `disconnect` method). The workaround in the `DatagramChannel::disconnect` is to attempt to
re-bind the channel's socket to its original port. This usually succeeds, but if it fails, an
`IOException` is thrown. This workaround has been used in the `DatagramSocket` implementation
for several releases.
As part of this change, the `javadoc` for `DatagramChannel::disconnect` has been updated with
an API note to make it clear that an `IOException` might leave the channel's socket in an
unspecified state. The API note also strongly recommends that the channel be closed when the
`disconnect` fails.
JDK-8231899: Zip File System Throws java.nio.file.NoSuchFileException When the File Does Not Exist and Is Not Being Created
The Zip File System has been updated to throw `java.nio.file.NoSuchFileException` (a
subclass of `IOException`), when `java.nio.file.FileSystems.newFileSystem` is used to create a
new file system; the specified Zip or JAR file does not exist, and the Zip provider property
`create` is not set to `true`.
JDK-8230045: Using the ZIP File System (zipfs) Provider to Update a ZIP or JAR File Containing Uncompressed Entries Might Corrupt the File
Using the ZIP File System (`zipfs`) to update a JAR or ZIP file might corrupt that file.
Corruption occurs only if the JAR or ZIP file contains a non-compressed entry. If the JAR or
ZIP file contains only compressed entries, as is typical, then no data corruption occurs.
As a workaround, users can use the `jar` tool or the `java.util.zip` API to update JAR or ZIP
files that contain non-compressed entries.
JDK-8240909: Clarify the Specification of ReadableByteChannel.read() and Related Methods
The specifications of the `DatagramChannel.receive()`, `FileChannel.read(ByteBuffer,long)`,
`ReadableByteChannel.read()`, and `ScatteringByteChannel.read()` methods have been updated in
this release to specify that an `IllegalArgumentException` is thrown if (any of) the buffer
parameter(s) is read-only. This change merely adjusts the specification to match existing long
term behavior.
JDK-8231881: DatagramChannel.disconnect Might Leave the Channel's Socket in an Unspecified State
The `DatagramChannel` implementation has been updated in this release so that the `disconnect`
method attempts to workaround Linux kernel behavior that reverts the local port to 0 after
dissolving the association. The issue arises when a `DatagramChannel` is initially bound to an
ephemeral port, connected (by calling its `connect` method), and then disconnected (by calling
its `disconnect` method). The workaround in the `DatagramChannel::disconnect` is to attempt to
re-bind the channel's socket to its original port. This usually succeeds, but if it fails, an
`IOException` is thrown. This workaround has been used in the `DatagramSocket` implementation
for several releases.
As part of this change, the `javadoc` for `DatagramChannel::disconnect` has been updated with
an API note to make it clear that an `IOException` might leave the channel's socket in an
unspecified state. The API note also strongly recommends that the channel be closed when the
`disconnect` fails.
JDK-8231899: Zip File System Throws java.nio.file.NoSuchFileException When the File Does Not Exist and Is Not Being Created
The Zip File System has been updated to throw `java.nio.file.NoSuchFileException` (a
subclass of `IOException`), when `java.nio.file.FileSystems.newFileSystem` is used to create a
new file system; the specified Zip or JAR file does not exist, and the Zip provider property
`create` is not set to `true`.
JDK-8230045: Using the ZIP File System (zipfs) Provider to Update a ZIP or JAR File Containing Uncompressed Entries Might Corrupt the File
Using the ZIP File System (`zipfs`) to update a JAR or ZIP file might corrupt that file.
Corruption occurs only if the JAR or ZIP file contains a non-compressed entry. If the JAR or
ZIP file contains only compressed entries, as is typical, then no data corruption occurs.
As a workaround, users can use the `jar` tool or the `java.util.zip` API to update JAR or ZIP
files that contain non-compressed entries.
JDK-8240909: Clarify the Specification of ReadableByteChannel.read() and Related Methods
The specifications of the `DatagramChannel.receive()`, `FileChannel.read(ByteBuffer,long)`,
`ReadableByteChannel.read()`, and `ScatteringByteChannel.read()` methods have been updated in
this release to specify that an `IllegalArgumentException` is thrown if (any of) the buffer
parameter(s) is read-only. This change merely adjusts the specification to match existing long
term behavior.
JDK-8231881: DatagramChannel.disconnect Might Leave the Channel's Socket in an Unspecified State
The `DatagramChannel` implementation has been updated in this release so that the `disconnect`
method attempts to workaround Linux kernel behavior that reverts the local port to 0 after
dissolving the association. The issue arises when a `DatagramChannel` is initially bound to an
ephemeral port, connected (by calling its `connect` method), and then disconnected (by calling
its `disconnect` method). The workaround in the `DatagramChannel::disconnect` is to attempt to
re-bind the channel's socket to its original port. This usually succeeds, but if it fails, an
`IOException` is thrown. This workaround has been used in the `DatagramSocket` implementation
for several releases.
As part of this change, the `javadoc` for `DatagramChannel::disconnect` has been updated with
an API note to make it clear that an `IOException` might leave the channel's socket in an
unspecified state. The API note also strongly recommends that the channel be closed when the
`disconnect` fails.
hotspot/jfr:
JDK-8242899: JEP 349: JFR Event Streaming
JDK Flight Recorder (JFR) now supports continuous monitoring of a Java application by allowing
events to be consumed dynamically using a new API located in the jdk.jfr.consumer package. The
feature is always enabled when using JFR, meaning recorded data up to the last second is
available for both in process and out of process consumption. See [JEP 349: JFR Event
Streaming](https://openjdk.java.net/jeps/349) for more information.
hotspot/gc:
JDK-8236248: Epsilon does not extend TLABs to max size
Due to a simple implementation bug, Epsilon GC did not extend the size of the issued TLABs to
the max size configured by user, or set by default. This bug might have introduced performance
penalties and was generally confusing during performance analysis. This is now fixed and
backported to 13u and 11u. Users are advised to double-check their performance results before
and after this update.
JDK-8237013: Shenandoah self-fixing barriers
Before this improvement, Shenandoah LRB barrier performance penalty for accessing forwarded
objects involved resolving through the forwarding pointer, until the Update References phase
fixed the affected references. A more efficient implementation ships now, where LRB self-fixes
the forwarded reference on the same code path, eliminating continuous resolves for potentially
hot accesses.
Self-fixing is implemented for C1 and C2 (JDK-8231087), interpreter (JDK-8232992) and runtime
(JDK-8232010) barriers.
JDK-8237011: Shenandoah CAS barriers improvements
Following the Load-Reference-Barriers work in JDK 13 (JDK-8221766), Shenandoah improves CAS
barriers to be more efficient. This may translate to higher performance in heavily concurrent
code that deals with lots of object reference CASes, e.g. with AtomicReference.compareAndSet,
VarHandle.compareAndSet, Unsafe.compareAndSet, etc.
JDK-8234585: JEP 366: Deprecate the ParallelScavenge + SerialOld GC Combination
The ParallelScavenge + SerialOld garbage collector combination has been deprecated. Any use of
the `UseParallelOldGC` command line option, which is used to enable this garbage collection
algorithm combination, will cause a deprecation warning.
The drop-in replacement is to use the ParallelScavenge + ParallelOld garbage collector through
`-XX:+UseParallelGC` on the command line.
See [JEP 366: Deprecate the ParallelScavenge + SerialOld GC
Combination](https://openjdk.java.net/jeps/366) for more information.
JDK-8237010: Shenandoah supports concurrent class unloading
As of JDK 14, Shenandoah GC supports concurrent class unloading. It improves the prior
stop-the-world implementation to be fully concurrent, which minimizes the class unloading work
done during Final Mark pause. This also enables class unloading for the regular GC cycles by
default, in addition to already enabled class unloading during degenerated and full GC cycles.
This relies heavily on runtime facilities introduced in JDK 12, and therefore not available in
11-shenandoah and 8-shenandoah.
JDK-8235755: Parallel GC Improvements
Parallel GC has adopted the same task management mechanism for scheduling parallel tasks as
other collectors. This might result in significant performance improvements. Because of this
change, the following product flags have been obsoleted: `-XX:BindGCTaskThreadsToCPUs`,
`-XX:UseGCTaskAffinity`, and `-XX:GCTaskTimeStampEntries`.
JDK-8235396: JEP 365: ZGC on Windows
The Z Garbage Collector (ZGC) is now available as an experimental feature on Windows. To
enable it, use the JVM flags `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`. See [JEP 365: ZGC
on Windows](https://openjdk.java.net/jeps/365) for more information.
JDK-8236245: Shenandoah: asynchronous object/region pinning
When dealing with JNI Get*Critical methods, Shenandoah employs object/region pinning, instead
of using the GCLocker. Until now, the inefficient pinning implementation have caused
real-world scalability problems on workloads that use a lot of JNI, for example gzip and
graphics. This was improved, and scalability bottleneck should be resolved. This fix was also
backported to 8-shenandoah and 11-shenandoah.
JDK-8237009: Shenandoah supports JFR Leak Profiler
After the recent improvements in runtime, users should now be able to use JFR Leak Profiler
with Shenandoah GC. This is only available with JDK 14 onwards.
JDK-8234141: JEP 345: NUMA-Aware Memory Allocation for G1
The G1 garbage collector now tries to allocate and keep objects on the same NUMA node in the
young generation across garbage collections. This is similar to Parallel GC NUMA awareness.
G1 attempts to evenly distribute Humongous and Old regions across all available NUMA nodes
using a strict interleave. Placement of objects copied from young to old generation is random.
These new NUMA-Aware Memory Allocation heuristics are automatically enabled by using the
`-XX:+UseNUMA` command line option. See [JEP 345: NUMA-Aware Memory Allocation for
G1](https://openjdk.java.net/jeps/345) for more information.
JDK-8234346: JEP 364: ZGC on macOS
The Z Garbage Collector (ZGC) is now available as an experimental feature on macOS. To enable
it, use the JVM flags `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`. See [JEP 364: ZGC on
macOS](https://openjdk.java.net/jeps/364) for more information.
JDK-8237012: Shenandoah arraycopy improvements
When handling Object[] arraycopy, Shenandoah used to evacuate array elements / fix references
in the destination array after the copy. This is not efficient when multiple copies are done,
as fixups would have to run on every copy. Plus, the fixups in the destination array do not
improve the accesses to the source array.
Unfortunately, this was the only way to deal with arraycopy until the GC API was extended. In
JDK 14 with GC API improvements, Shenandoah is now able to fix up object arrays at source
before the arraycopy, which improves performance and opens up other optimization
opportunities.
JDK-8237016: Epsilon warns about Xms/Xmx/AlwaysPreTouch configuration
Many Epsilon GC users expect low latency, but may not be aware that additional configuration
is needed for GCs to perform well in those conditions. It now warns about
Xms/Xmx/AlwaysPreTouch configuration. These settings are not adjusted automatically, because
doing so would affect startup time. These new warnings can be shunned by overriding the
default logging level with -Xlog:gc=error.
JDK-8233390: JEP 363: Remove the Concurrent Mark and Sweep (CMS) Garbage Collector
The CMS garbage collector has been removed. `-XX:UseConcMarkSweepGC` and aliases `-Xconcgc`
and `-Xnoconcgc` are obsoleted as well as all CMS specific options (too many to list). See
[JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage
Collector](https://openjdk.java.net/jeps/363) for more information.
JDK-8236248: Epsilon does not extend TLABs to max size
Due to a simple implementation bug, Epsilon GC did not extend the size of the issued TLABs to
the max size configured by user, or set by default. This bug might have introduced performance
penalties and was generally confusing during performance analysis. This is now fixed and
backported to 13u and 11u. Users are advised to double-check their performance results before
and after this update.
JDK-8237013: Shenandoah self-fixing barriers
Before this improvement, Shenandoah LRB barrier performance penalty for accessing forwarded
objects involved resolving through the forwarding pointer, until the Update References phase
fixed the affected references. A more efficient implementation ships now, where LRB self-fixes
the forwarded reference on the same code path, eliminating continuous resolves for potentially
hot accesses.
Self-fixing is implemented for C1 and C2 (JDK-8231087), interpreter (JDK-8232992) and runtime
(JDK-8232010) barriers.
JDK-8237011: Shenandoah CAS barriers improvements
Following the Load-Reference-Barriers work in JDK 13 (JDK-8221766), Shenandoah improves CAS
barriers to be more efficient. This may translate to higher performance in heavily concurrent
code that deals with lots of object reference CASes, e.g. with AtomicReference.compareAndSet,
VarHandle.compareAndSet, Unsafe.compareAndSet, etc.
JDK-8234585: JEP 366: Deprecate the ParallelScavenge + SerialOld GC Combination
The ParallelScavenge + SerialOld garbage collector combination has been deprecated. Any use of
the `UseParallelOldGC` command line option, which is used to enable this garbage collection
algorithm combination, will cause a deprecation warning.
The drop-in replacement is to use the ParallelScavenge + ParallelOld garbage collector through
`-XX:+UseParallelGC` on the command line.
See [JEP 366: Deprecate the ParallelScavenge + SerialOld GC
Combination](https://openjdk.java.net/jeps/366) for more information.
JDK-8237010: Shenandoah supports concurrent class unloading
As of JDK 14, Shenandoah GC supports concurrent class unloading. It improves the prior
stop-the-world implementation to be fully concurrent, which minimizes the class unloading work
done during Final Mark pause. This also enables class unloading for the regular GC cycles by
default, in addition to already enabled class unloading during degenerated and full GC cycles.
This relies heavily on runtime facilities introduced in JDK 12, and therefore not available in
11-shenandoah and 8-shenandoah.
JDK-8235755: Parallel GC Improvements
Parallel GC has adopted the same task management mechanism for scheduling parallel tasks as
other collectors. This might result in significant performance improvements. Because of this
change, the following product flags have been obsoleted: `-XX:BindGCTaskThreadsToCPUs`,
`-XX:UseGCTaskAffinity`, and `-XX:GCTaskTimeStampEntries`.
JDK-8235396: JEP 365: ZGC on Windows
The Z Garbage Collector (ZGC) is now available as an experimental feature on Windows. To
enable it, use the JVM flags `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`. See [JEP 365: ZGC
on Windows](https://openjdk.java.net/jeps/365) for more information.
JDK-8236245: Shenandoah: asynchronous object/region pinning
When dealing with JNI Get*Critical methods, Shenandoah employs object/region pinning, instead
of using the GCLocker. Until now, the inefficient pinning implementation have caused
real-world scalability problems on workloads that use a lot of JNI, for example gzip and
graphics. This was improved, and scalability bottleneck should be resolved. This fix was also
backported to 8-shenandoah and 11-shenandoah.
JDK-8237009: Shenandoah supports JFR Leak Profiler
After the recent improvements in runtime, users should now be able to use JFR Leak Profiler
with Shenandoah GC. This is only available with JDK 14 onwards.
JDK-8234141: JEP 345: NUMA-Aware Memory Allocation for G1
The G1 garbage collector now tries to allocate and keep objects on the same NUMA node in the
young generation across garbage collections. This is similar to Parallel GC NUMA awareness.
G1 attempts to evenly distribute Humongous and Old regions across all available NUMA nodes
using a strict interleave. Placement of objects copied from young to old generation is random.
These new NUMA-Aware Memory Allocation heuristics are automatically enabled by using the
`-XX:+UseNUMA` command line option. See [JEP 345: NUMA-Aware Memory Allocation for
G1](https://openjdk.java.net/jeps/345) for more information.
JDK-8234346: JEP 364: ZGC on macOS
The Z Garbage Collector (ZGC) is now available as an experimental feature on macOS. To enable
it, use the JVM flags `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`. See [JEP 364: ZGC on
macOS](https://openjdk.java.net/jeps/364) for more information.
JDK-8237012: Shenandoah arraycopy improvements
When handling Object[] arraycopy, Shenandoah used to evacuate array elements / fix references
in the destination array after the copy. This is not efficient when multiple copies are done,
as fixups would have to run on every copy. Plus, the fixups in the destination array do not
improve the accesses to the source array.
Unfortunately, this was the only way to deal with arraycopy until the GC API was extended. In
JDK 14 with GC API improvements, Shenandoah is now able to fix up object arrays at source
before the arraycopy, which improves performance and opens up other optimization
opportunities.
JDK-8237016: Epsilon warns about Xms/Xmx/AlwaysPreTouch configuration
Many Epsilon GC users expect low latency, but may not be aware that additional configuration
is needed for GCs to perform well in those conditions. It now warns about
Xms/Xmx/AlwaysPreTouch configuration. These settings are not adjusted automatically, because
doing so would affect startup time. These new warnings can be shunned by overriding the
default logging level with -Xlog:gc=error.
JDK-8233390: JEP 363: Remove the Concurrent Mark and Sweep (CMS) Garbage Collector
The CMS garbage collector has been removed. `-XX:UseConcMarkSweepGC` and aliases `-Xconcgc`
and `-Xnoconcgc` are obsoleted as well as all CMS specific options (too many to list). See
[JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage
Collector](https://openjdk.java.net/jeps/363) for more information.
JDK-8236248: Epsilon does not extend TLABs to max size
Due to a simple implementation bug, Epsilon GC did not extend the size of the issued TLABs to
the max size configured by user, or set by default. This bug might have introduced performance
penalties and was generally confusing during performance analysis. This is now fixed and
backported to 13u and 11u. Users are advised to double-check their performance results before
and after this update.
JDK-8237013: Shenandoah self-fixing barriers
Before this improvement, Shenandoah LRB barrier performance penalty for accessing forwarded
objects involved resolving through the forwarding pointer, until the Update References phase
fixed the affected references. A more efficient implementation ships now, where LRB self-fixes
the forwarded reference on the same code path, eliminating continuous resolves for potentially
hot accesses.
Self-fixing is implemented for C1 and C2 (JDK-8231087), interpreter (JDK-8232992) and runtime
(JDK-8232010) barriers.
JDK-8237011: Shenandoah CAS barriers improvements
Following the Load-Reference-Barriers work in JDK 13 (JDK-8221766), Shenandoah improves CAS
barriers to be more efficient. This may translate to higher performance in heavily concurrent
code that deals with lots of object reference CASes, e.g. with AtomicReference.compareAndSet,
VarHandle.compareAndSet, Unsafe.compareAndSet, etc.
JDK-8234585: JEP 366: Deprecate the ParallelScavenge + SerialOld GC Combination
The ParallelScavenge + SerialOld garbage collector combination has been deprecated. Any use of
the `UseParallelOldGC` command line option, which is used to enable this garbage collection
algorithm combination, will cause a deprecation warning.
The drop-in replacement is to use the ParallelScavenge + ParallelOld garbage collector through
`-XX:+UseParallelGC` on the command line.
See [JEP 366: Deprecate the ParallelScavenge + SerialOld GC
Combination](https://openjdk.java.net/jeps/366) for more information.
JDK-8237010: Shenandoah supports concurrent class unloading
As of JDK 14, Shenandoah GC supports concurrent class unloading. It improves the prior
stop-the-world implementation to be fully concurrent, which minimizes the class unloading work
done during Final Mark pause. This also enables class unloading for the regular GC cycles by
default, in addition to already enabled class unloading during degenerated and full GC cycles.
This relies heavily on runtime facilities introduced in JDK 12, and therefore not available in
11-shenandoah and 8-shenandoah.
JDK-8235755: Parallel GC Improvements
Parallel GC has adopted the same task management mechanism for scheduling parallel tasks as
other collectors. This might result in significant performance improvements. Because of this
change, the following product flags have been obsoleted: `-XX:BindGCTaskThreadsToCPUs`,
`-XX:UseGCTaskAffinity`, and `-XX:GCTaskTimeStampEntries`.
JDK-8235396: JEP 365: ZGC on Windows
The Z Garbage Collector (ZGC) is now available as an experimental feature on Windows. To
enable it, use the JVM flags `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`. See [JEP 365: ZGC
on Windows](https://openjdk.java.net/jeps/365) for more information.
JDK-8236245: Shenandoah: asynchronous object/region pinning
When dealing with JNI Get*Critical methods, Shenandoah employs object/region pinning, instead
of using the GCLocker. Until now, the inefficient pinning implementation have caused
real-world scalability problems on workloads that use a lot of JNI, for example gzip and
graphics. This was improved, and scalability bottleneck should be resolved. This fix was also
backported to 8-shenandoah and 11-shenandoah.
JDK-8237009: Shenandoah supports JFR Leak Profiler
After the recent improvements in runtime, users should now be able to use JFR Leak Profiler
with Shenandoah GC. This is only available with JDK 14 onwards.
JDK-8234141: JEP 345: NUMA-Aware Memory Allocation for G1
The G1 garbage collector now tries to allocate and keep objects on the same NUMA node in the
young generation across garbage collections. This is similar to Parallel GC NUMA awareness.
G1 attempts to evenly distribute Humongous and Old regions across all available NUMA nodes
using a strict interleave. Placement of objects copied from young to old generation is random.
These new NUMA-Aware Memory Allocation heuristics are automatically enabled by using the
`-XX:+UseNUMA` command line option. See [JEP 345: NUMA-Aware Memory Allocation for
G1](https://openjdk.java.net/jeps/345) for more information.
JDK-8234346: JEP 364: ZGC on macOS
The Z Garbage Collector (ZGC) is now available as an experimental feature on macOS. To enable
it, use the JVM flags `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`. See [JEP 364: ZGC on
macOS](https://openjdk.java.net/jeps/364) for more information.
JDK-8237012: Shenandoah arraycopy improvements
When handling Object[] arraycopy, Shenandoah used to evacuate array elements / fix references
in the destination array after the copy. This is not efficient when multiple copies are done,
as fixups would have to run on every copy. Plus, the fixups in the destination array do not
improve the accesses to the source array.
Unfortunately, this was the only way to deal with arraycopy until the GC API was extended. In
JDK 14 with GC API improvements, Shenandoah is now able to fix up object arrays at source
before the arraycopy, which improves performance and opens up other optimization
opportunities.
JDK-8237016: Epsilon warns about Xms/Xmx/AlwaysPreTouch configuration
Many Epsilon GC users expect low latency, but may not be aware that additional configuration
is needed for GCs to perform well in those conditions. It now warns about
Xms/Xmx/AlwaysPreTouch configuration. These settings are not adjusted automatically, because
doing so would affect startup time. These new warnings can be shunned by overriding the
default logging level with -Xlog:gc=error.
JDK-8233390: JEP 363: Remove the Concurrent Mark and Sweep (CMS) Garbage Collector
The CMS garbage collector has been removed. `-XX:UseConcMarkSweepGC` and aliases `-Xconcgc`
and `-Xnoconcgc` are obsoleted as well as all CMS specific options (too many to list). See
[JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage
Collector](https://openjdk.java.net/jeps/363) for more information.
JDK-8236248: Epsilon does not extend TLABs to max size
Due to a simple implementation bug, Epsilon GC did not extend the size of the issued TLABs to
the max size configured by user, or set by default. This bug might have introduced performance
penalties and was generally confusing during performance analysis. This is now fixed and
backported to 13u and 11u. Users are advised to double-check their performance results before
and after this update.
JDK-8237013: Shenandoah self-fixing barriers
Before this improvement, Shenandoah LRB barrier performance penalty for accessing forwarded
objects involved resolving through the forwarding pointer, until the Update References phase
fixed the affected references. A more efficient implementation ships now, where LRB self-fixes
the forwarded reference on the same code path, eliminating continuous resolves for potentially
hot accesses.
Self-fixing is implemented for C1 and C2 (JDK-8231087), interpreter (JDK-8232992) and runtime
(JDK-8232010) barriers.
JDK-8237011: Shenandoah CAS barriers improvements
Following the Load-Reference-Barriers work in JDK 13 (JDK-8221766), Shenandoah improves CAS
barriers to be more efficient. This may translate to higher performance in heavily concurrent
code that deals with lots of object reference CASes, e.g. with AtomicReference.compareAndSet,
VarHandle.compareAndSet, Unsafe.compareAndSet, etc.
JDK-8234585: JEP 366: Deprecate the ParallelScavenge + SerialOld GC Combination
The ParallelScavenge + SerialOld garbage collector combination has been deprecated. Any use of
the `UseParallelOldGC` command line option, which is used to enable this garbage collection
algorithm combination, will cause a deprecation warning.
The drop-in replacement is to use the ParallelScavenge + ParallelOld garbage collector through
`-XX:+UseParallelGC` on the command line.
See [JEP 366: Deprecate the ParallelScavenge + SerialOld GC
Combination](https://openjdk.java.net/jeps/366) for more information.
JDK-8237010: Shenandoah supports concurrent class unloading
As of JDK 14, Shenandoah GC supports concurrent class unloading. It improves the prior
stop-the-world implementation to be fully concurrent, which minimizes the class unloading work
done during Final Mark pause. This also enables class unloading for the regular GC cycles by
default, in addition to already enabled class unloading during degenerated and full GC cycles.
This relies heavily on runtime facilities introduced in JDK 12, and therefore not available in
11-shenandoah and 8-shenandoah.
JDK-8235755: Parallel GC Improvements
Parallel GC has adopted the same task management mechanism for scheduling parallel tasks as
other collectors. This might result in significant performance improvements. Because of this
change, the following product flags have been obsoleted: `-XX:BindGCTaskThreadsToCPUs`,
`-XX:UseGCTaskAffinity`, and `-XX:GCTaskTimeStampEntries`.
JDK-8235396: JEP 365: ZGC on Windows
The Z Garbage Collector (ZGC) is now available as an experimental feature on Windows. To
enable it, use the JVM flags `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`. See [JEP 365: ZGC
on Windows](https://openjdk.java.net/jeps/365) for more information.
JDK-8236245: Shenandoah: asynchronous object/region pinning
When dealing with JNI Get*Critical methods, Shenandoah employs object/region pinning, instead
of using the GCLocker. Until now, the inefficient pinning implementation have caused
real-world scalability problems on workloads that use a lot of JNI, for example gzip and
graphics. This was improved, and scalability bottleneck should be resolved. This fix was also
backported to 8-shenandoah and 11-shenandoah.
JDK-8237009: Shenandoah supports JFR Leak Profiler
After the recent improvements in runtime, users should now be able to use JFR Leak Profiler
with Shenandoah GC. This is only available with JDK 14 onwards.
JDK-8234141: JEP 345: NUMA-Aware Memory Allocation for G1
The G1 garbage collector now tries to allocate and keep objects on the same NUMA node in the
young generation across garbage collections. This is similar to Parallel GC NUMA awareness.
G1 attempts to evenly distribute Humongous and Old regions across all available NUMA nodes
using a strict interleave. Placement of objects copied from young to old generation is random.
These new NUMA-Aware Memory Allocation heuristics are automatically enabled by using the
`-XX:+UseNUMA` command line option. See [JEP 345: NUMA-Aware Memory Allocation for
G1](https://openjdk.java.net/jeps/345) for more information.
JDK-8234346: JEP 364: ZGC on macOS
The Z Garbage Collector (ZGC) is now available as an experimental feature on macOS. To enable
it, use the JVM flags `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`. See [JEP 364: ZGC on
macOS](https://openjdk.java.net/jeps/364) for more information.
JDK-8237012: Shenandoah arraycopy improvements
When handling Object[] arraycopy, Shenandoah used to evacuate array elements / fix references
in the destination array after the copy. This is not efficient when multiple copies are done,
as fixups would have to run on every copy. Plus, the fixups in the destination array do not
improve the accesses to the source array.
Unfortunately, this was the only way to deal with arraycopy until the GC API was extended. In
JDK 14 with GC API improvements, Shenandoah is now able to fix up object arrays at source
before the arraycopy, which improves performance and opens up other optimization
opportunities.
JDK-8237016: Epsilon warns about Xms/Xmx/AlwaysPreTouch configuration
Many Epsilon GC users expect low latency, but may not be aware that additional configuration
is needed for GCs to perform well in those conditions. It now warns about
Xms/Xmx/AlwaysPreTouch configuration. These settings are not adjusted automatically, because
doing so would affect startup time. These new warnings can be shunned by overriding the
default logging level with -Xlog:gc=error.
JDK-8233390: JEP 363: Remove the Concurrent Mark and Sweep (CMS) Garbage Collector
The CMS garbage collector has been removed. `-XX:UseConcMarkSweepGC` and aliases `-Xconcgc`
and `-Xnoconcgc` are obsoleted as well as all CMS specific options (too many to list). See
[JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage
Collector](https://openjdk.java.net/jeps/363) for more information.
JDK-8236248: Epsilon does not extend TLABs to max size
Due to a simple implementation bug, Epsilon GC did not extend the size of the issued TLABs to
the max size configured by user, or set by default. This bug might have introduced performance
penalties and was generally confusing during performance analysis. This is now fixed and
backported to 13u and 11u. Users are advised to double-check their performance results before
and after this update.
JDK-8237013: Shenandoah self-fixing barriers
Before this improvement, Shenandoah LRB barrier performance penalty for accessing forwarded
objects involved resolving through the forwarding pointer, until the Update References phase
fixed the affected references. A more efficient implementation ships now, where LRB self-fixes
the forwarded reference on the same code path, eliminating continuous resolves for potentially
hot accesses.
Self-fixing is implemented for C1 and C2 (JDK-8231087), interpreter (JDK-8232992) and runtime
(JDK-8232010) barriers.
JDK-8237011: Shenandoah CAS barriers improvements
Following the Load-Reference-Barriers work in JDK 13 (JDK-8221766), Shenandoah improves CAS
barriers to be more efficient. This may translate to higher performance in heavily concurrent
code that deals with lots of object reference CASes, e.g. with AtomicReference.compareAndSet,
VarHandle.compareAndSet, Unsafe.compareAndSet, etc.
JDK-8234585: JEP 366: Deprecate the ParallelScavenge + SerialOld GC Combination
The ParallelScavenge + SerialOld garbage collector combination has been deprecated. Any use of
the `UseParallelOldGC` command line option, which is used to enable this garbage collection
algorithm combination, will cause a deprecation warning.
The drop-in replacement is to use the ParallelScavenge + ParallelOld garbage collector through
`-XX:+UseParallelGC` on the command line.
See [JEP 366: Deprecate the ParallelScavenge + SerialOld GC
Combination](https://openjdk.java.net/jeps/366) for more information.
JDK-8237010: Shenandoah supports concurrent class unloading
As of JDK 14, Shenandoah GC supports concurrent class unloading. It improves the prior
stop-the-world implementation to be fully concurrent, which minimizes the class unloading work
done during Final Mark pause. This also enables class unloading for the regular GC cycles by
default, in addition to already enabled class unloading during degenerated and full GC cycles.
This relies heavily on runtime facilities introduced in JDK 12, and therefore not available in
11-shenandoah and 8-shenandoah.
JDK-8235755: Parallel GC Improvements
Parallel GC has adopted the same task management mechanism for scheduling parallel tasks as
other collectors. This might result in significant performance improvements. Because of this
change, the following product flags have been obsoleted: `-XX:BindGCTaskThreadsToCPUs`,
`-XX:UseGCTaskAffinity`, and `-XX:GCTaskTimeStampEntries`.
JDK-8235396: JEP 365: ZGC on Windows
The Z Garbage Collector (ZGC) is now available as an experimental feature on Windows. To
enable it, use the JVM flags `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`. See [JEP 365: ZGC
on Windows](https://openjdk.java.net/jeps/365) for more information.
JDK-8236245: Shenandoah: asynchronous object/region pinning
When dealing with JNI Get*Critical methods, Shenandoah employs object/region pinning, instead
of using the GCLocker. Until now, the inefficient pinning implementation have caused
real-world scalability problems on workloads that use a lot of JNI, for example gzip and
graphics. This was improved, and scalability bottleneck should be resolved. This fix was also
backported to 8-shenandoah and 11-shenandoah.
JDK-8237009: Shenandoah supports JFR Leak Profiler
After the recent improvements in runtime, users should now be able to use JFR Leak Profiler
with Shenandoah GC. This is only available with JDK 14 onwards.
JDK-8234141: JEP 345: NUMA-Aware Memory Allocation for G1
The G1 garbage collector now tries to allocate and keep objects on the same NUMA node in the
young generation across garbage collections. This is similar to Parallel GC NUMA awareness.
G1 attempts to evenly distribute Humongous and Old regions across all available NUMA nodes
using a strict interleave. Placement of objects copied from young to old generation is random.
These new NUMA-Aware Memory Allocation heuristics are automatically enabled by using the
`-XX:+UseNUMA` command line option. See [JEP 345: NUMA-Aware Memory Allocation for
G1](https://openjdk.java.net/jeps/345) for more information.
JDK-8234346: JEP 364: ZGC on macOS
The Z Garbage Collector (ZGC) is now available as an experimental feature on macOS. To enable
it, use the JVM flags `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`. See [JEP 364: ZGC on
macOS](https://openjdk.java.net/jeps/364) for more information.
JDK-8237012: Shenandoah arraycopy improvements
When handling Object[] arraycopy, Shenandoah used to evacuate array elements / fix references
in the destination array after the copy. This is not efficient when multiple copies are done,
as fixups would have to run on every copy. Plus, the fixups in the destination array do not
improve the accesses to the source array.
Unfortunately, this was the only way to deal with arraycopy until the GC API was extended. In
JDK 14 with GC API improvements, Shenandoah is now able to fix up object arrays at source
before the arraycopy, which improves performance and opens up other optimization
opportunities.
JDK-8237016: Epsilon warns about Xms/Xmx/AlwaysPreTouch configuration
Many Epsilon GC users expect low latency, but may not be aware that additional configuration
is needed for GCs to perform well in those conditions. It now warns about
Xms/Xmx/AlwaysPreTouch configuration. These settings are not adjusted automatically, because
doing so would affect startup time. These new warnings can be shunned by overriding the
default logging level with -Xlog:gc=error.
JDK-8233390: JEP 363: Remove the Concurrent Mark and Sweep (CMS) Garbage Collector
The CMS garbage collector has been removed. `-XX:UseConcMarkSweepGC` and aliases `-Xconcgc`
and `-Xnoconcgc` are obsoleted as well as all CMS specific options (too many to list). See
[JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage
Collector](https://openjdk.java.net/jeps/363) for more information.
JDK-8236248: Epsilon does not extend TLABs to max size
Due to a simple implementation bug, Epsilon GC did not extend the size of the issued TLABs to
the max size configured by user, or set by default. This bug might have introduced performance
penalties and was generally confusing during performance analysis. This is now fixed and
backported to 13u and 11u. Users are advised to double-check their performance results before
and after this update.
JDK-8237013: Shenandoah self-fixing barriers
Before this improvement, Shenandoah LRB barrier performance penalty for accessing forwarded
objects involved resolving through the forwarding pointer, until the Update References phase
fixed the affected references. A more efficient implementation ships now, where LRB self-fixes
the forwarded reference on the same code path, eliminating continuous resolves for potentially
hot accesses.
Self-fixing is implemented for C1 and C2 (JDK-8231087), interpreter (JDK-8232992) and runtime
(JDK-8232010) barriers.
JDK-8237011: Shenandoah CAS barriers improvements
Following the Load-Reference-Barriers work in JDK 13 (JDK-8221766), Shenandoah improves CAS
barriers to be more efficient. This may translate to higher performance in heavily concurrent
code that deals with lots of object reference CASes, e.g. with AtomicReference.compareAndSet,
VarHandle.compareAndSet, Unsafe.compareAndSet, etc.
JDK-8234585: JEP 366: Deprecate the ParallelScavenge + SerialOld GC Combination
The ParallelScavenge + SerialOld garbage collector combination has been deprecated. Any use of
the `UseParallelOldGC` command line option, which is used to enable this garbage collection
algorithm combination, will cause a deprecation warning.
The drop-in replacement is to use the ParallelScavenge + ParallelOld garbage collector through
`-XX:+UseParallelGC` on the command line.
See [JEP 366: Deprecate the ParallelScavenge + SerialOld GC
Combination](https://openjdk.java.net/jeps/366) for more information.
JDK-8237010: Shenandoah supports concurrent class unloading
As of JDK 14, Shenandoah GC supports concurrent class unloading. It improves the prior
stop-the-world implementation to be fully concurrent, which minimizes the class unloading work
done during Final Mark pause. This also enables class unloading for the regular GC cycles by
default, in addition to already enabled class unloading during degenerated and full GC cycles.
This relies heavily on runtime facilities introduced in JDK 12, and therefore not available in
11-shenandoah and 8-shenandoah.
JDK-8235755: Parallel GC Improvements
Parallel GC has adopted the same task management mechanism for scheduling parallel tasks as
other collectors. This might result in significant performance improvements. Because of this
change, the following product flags have been obsoleted: `-XX:BindGCTaskThreadsToCPUs`,
`-XX:UseGCTaskAffinity`, and `-XX:GCTaskTimeStampEntries`.
JDK-8235396: JEP 365: ZGC on Windows
The Z Garbage Collector (ZGC) is now available as an experimental feature on Windows. To
enable it, use the JVM flags `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`. See [JEP 365: ZGC
on Windows](https://openjdk.java.net/jeps/365) for more information.
JDK-8236245: Shenandoah: asynchronous object/region pinning
When dealing with JNI Get*Critical methods, Shenandoah employs object/region pinning, instead
of using the GCLocker. Until now, the inefficient pinning implementation have caused
real-world scalability problems on workloads that use a lot of JNI, for example gzip and
graphics. This was improved, and scalability bottleneck should be resolved. This fix was also
backported to 8-shenandoah and 11-shenandoah.
JDK-8237009: Shenandoah supports JFR Leak Profiler
After the recent improvements in runtime, users should now be able to use JFR Leak Profiler
with Shenandoah GC. This is only available with JDK 14 onwards.
JDK-8234141: JEP 345: NUMA-Aware Memory Allocation for G1
The G1 garbage collector now tries to allocate and keep objects on the same NUMA node in the
young generation across garbage collections. This is similar to Parallel GC NUMA awareness.
G1 attempts to evenly distribute Humongous and Old regions across all available NUMA nodes
using a strict interleave. Placement of objects copied from young to old generation is random.
These new NUMA-Aware Memory Allocation heuristics are automatically enabled by using the
`-XX:+UseNUMA` command line option. See [JEP 345: NUMA-Aware Memory Allocation for
G1](https://openjdk.java.net/jeps/345) for more information.
JDK-8234346: JEP 364: ZGC on macOS
The Z Garbage Collector (ZGC) is now available as an experimental feature on macOS. To enable
it, use the JVM flags `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`. See [JEP 364: ZGC on
macOS](https://openjdk.java.net/jeps/364) for more information.
JDK-8237012: Shenandoah arraycopy improvements
When handling Object[] arraycopy, Shenandoah used to evacuate array elements / fix references
in the destination array after the copy. This is not efficient when multiple copies are done,
as fixups would have to run on every copy. Plus, the fixups in the destination array do not
improve the accesses to the source array.
Unfortunately, this was the only way to deal with arraycopy until the GC API was extended. In
JDK 14 with GC API improvements, Shenandoah is now able to fix up object arrays at source
before the arraycopy, which improves performance and opens up other optimization
opportunities.
JDK-8237016: Epsilon warns about Xms/Xmx/AlwaysPreTouch configuration
Many Epsilon GC users expect low latency, but may not be aware that additional configuration
is needed for GCs to perform well in those conditions. It now warns about
Xms/Xmx/AlwaysPreTouch configuration. These settings are not adjusted automatically, because
doing so would affect startup time. These new warnings can be shunned by overriding the
default logging level with -Xlog:gc=error.
JDK-8233390: JEP 363: Remove the Concurrent Mark and Sweep (CMS) Garbage Collector
The CMS garbage collector has been removed. `-XX:UseConcMarkSweepGC` and aliases `-Xconcgc`
and `-Xnoconcgc` are obsoleted as well as all CMS specific options (too many to list). See
[JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage
Collector](https://openjdk.java.net/jeps/363) for more information.
JDK-8236248: Epsilon does not extend TLABs to max size
Due to a simple implementation bug, Epsilon GC did not extend the size of the issued TLABs to
the max size configured by user, or set by default. This bug might have introduced performance
penalties and was generally confusing during performance analysis. This is now fixed and
backported to 13u and 11u. Users are advised to double-check their performance results before
and after this update.
JDK-8237013: Shenandoah self-fixing barriers
Before this improvement, Shenandoah LRB barrier performance penalty for accessing forwarded
objects involved resolving through the forwarding pointer, until the Update References phase
fixed the affected references. A more efficient implementation ships now, where LRB self-fixes
the forwarded reference on the same code path, eliminating continuous resolves for potentially
hot accesses.
Self-fixing is implemented for C1 and C2 (JDK-8231087), interpreter (JDK-8232992) and runtime
(JDK-8232010) barriers.
JDK-8237011: Shenandoah CAS barriers improvements
Following the Load-Reference-Barriers work in JDK 13 (JDK-8221766), Shenandoah improves CAS
barriers to be more efficient. This may translate to higher performance in heavily concurrent
code that deals with lots of object reference CASes, e.g. with AtomicReference.compareAndSet,
VarHandle.compareAndSet, Unsafe.compareAndSet, etc.
JDK-8234585: JEP 366: Deprecate the ParallelScavenge + SerialOld GC Combination
The ParallelScavenge + SerialOld garbage collector combination has been deprecated. Any use of
the `UseParallelOldGC` command line option, which is used to enable this garbage collection
algorithm combination, will cause a deprecation warning.
The drop-in replacement is to use the ParallelScavenge + ParallelOld garbage collector through
`-XX:+UseParallelGC` on the command line.
See [JEP 366: Deprecate the ParallelScavenge + SerialOld GC
Combination](https://openjdk.java.net/jeps/366) for more information.
JDK-8237010: Shenandoah supports concurrent class unloading
As of JDK 14, Shenandoah GC supports concurrent class unloading. It improves the prior
stop-the-world implementation to be fully concurrent, which minimizes the class unloading work
done during Final Mark pause. This also enables class unloading for the regular GC cycles by
default, in addition to already enabled class unloading during degenerated and full GC cycles.
This relies heavily on runtime facilities introduced in JDK 12, and therefore not available in
11-shenandoah and 8-shenandoah.
JDK-8235755: Parallel GC Improvements
Parallel GC has adopted the same task management mechanism for scheduling parallel tasks as
other collectors. This might result in significant performance improvements. Because of this
change, the following product flags have been obsoleted: `-XX:BindGCTaskThreadsToCPUs`,
`-XX:UseGCTaskAffinity`, and `-XX:GCTaskTimeStampEntries`.
JDK-8235396: JEP 365: ZGC on Windows
The Z Garbage Collector (ZGC) is now available as an experimental feature on Windows. To
enable it, use the JVM flags `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`. See [JEP 365: ZGC
on Windows](https://openjdk.java.net/jeps/365) for more information.
JDK-8236245: Shenandoah: asynchronous object/region pinning
When dealing with JNI Get*Critical methods, Shenandoah employs object/region pinning, instead
of using the GCLocker. Until now, the inefficient pinning implementation have caused
real-world scalability problems on workloads that use a lot of JNI, for example gzip and
graphics. This was improved, and scalability bottleneck should be resolved. This fix was also
backported to 8-shenandoah and 11-shenandoah.
JDK-8237009: Shenandoah supports JFR Leak Profiler
After the recent improvements in runtime, users should now be able to use JFR Leak Profiler
with Shenandoah GC. This is only available with JDK 14 onwards.
JDK-8234141: JEP 345: NUMA-Aware Memory Allocation for G1
The G1 garbage collector now tries to allocate and keep objects on the same NUMA node in the
young generation across garbage collections. This is similar to Parallel GC NUMA awareness.
G1 attempts to evenly distribute Humongous and Old regions across all available NUMA nodes
using a strict interleave. Placement of objects copied from young to old generation is random.
These new NUMA-Aware Memory Allocation heuristics are automatically enabled by using the
`-XX:+UseNUMA` command line option. See [JEP 345: NUMA-Aware Memory Allocation for
G1](https://openjdk.java.net/jeps/345) for more information.
JDK-8234346: JEP 364: ZGC on macOS
The Z Garbage Collector (ZGC) is now available as an experimental feature on macOS. To enable
it, use the JVM flags `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`. See [JEP 364: ZGC on
macOS](https://openjdk.java.net/jeps/364) for more information.
JDK-8237012: Shenandoah arraycopy improvements
When handling Object[] arraycopy, Shenandoah used to evacuate array elements / fix references
in the destination array after the copy. This is not efficient when multiple copies are done,
as fixups would have to run on every copy. Plus, the fixups in the destination array do not
improve the accesses to the source array.
Unfortunately, this was the only way to deal with arraycopy until the GC API was extended. In
JDK 14 with GC API improvements, Shenandoah is now able to fix up object arrays at source
before the arraycopy, which improves performance and opens up other optimization
opportunities.
JDK-8237016: Epsilon warns about Xms/Xmx/AlwaysPreTouch configuration
Many Epsilon GC users expect low latency, but may not be aware that additional configuration
is needed for GCs to perform well in those conditions. It now warns about
Xms/Xmx/AlwaysPreTouch configuration. These settings are not adjusted automatically, because
doing so would affect startup time. These new warnings can be shunned by overriding the
default logging level with -Xlog:gc=error.
JDK-8233390: JEP 363: Remove the Concurrent Mark and Sweep (CMS) Garbage Collector
The CMS garbage collector has been removed. `-XX:UseConcMarkSweepGC` and aliases `-Xconcgc`
and `-Xnoconcgc` are obsoleted as well as all CMS specific options (too many to list). See
[JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage
Collector](https://openjdk.java.net/jeps/363) for more information.
JDK-8236248: Epsilon does not extend TLABs to max size
Due to a simple implementation bug, Epsilon GC did not extend the size of the issued TLABs to
the max size configured by user, or set by default. This bug might have introduced performance
penalties and was generally confusing during performance analysis. This is now fixed and
backported to 13u and 11u. Users are advised to double-check their performance results before
and after this update.
JDK-8237013: Shenandoah self-fixing barriers
Before this improvement, Shenandoah LRB barrier performance penalty for accessing forwarded
objects involved resolving through the forwarding pointer, until the Update References phase
fixed the affected references. A more efficient implementation ships now, where LRB self-fixes
the forwarded reference on the same code path, eliminating continuous resolves for potentially
hot accesses.
Self-fixing is implemented for C1 and C2 (JDK-8231087), interpreter (JDK-8232992) and runtime
(JDK-8232010) barriers.
JDK-8237011: Shenandoah CAS barriers improvements
Following the Load-Reference-Barriers work in JDK 13 (JDK-8221766), Shenandoah improves CAS
barriers to be more efficient. This may translate to higher performance in heavily concurrent
code that deals with lots of object reference CASes, e.g. with AtomicReference.compareAndSet,
VarHandle.compareAndSet, Unsafe.compareAndSet, etc.
JDK-8234585: JEP 366: Deprecate the ParallelScavenge + SerialOld GC Combination
The ParallelScavenge + SerialOld garbage collector combination has been deprecated. Any use of
the `UseParallelOldGC` command line option, which is used to enable this garbage collection
algorithm combination, will cause a deprecation warning.
The drop-in replacement is to use the ParallelScavenge + ParallelOld garbage collector through
`-XX:+UseParallelGC` on the command line.
See [JEP 366: Deprecate the ParallelScavenge + SerialOld GC
Combination](https://openjdk.java.net/jeps/366) for more information.
JDK-8237010: Shenandoah supports concurrent class unloading
As of JDK 14, Shenandoah GC supports concurrent class unloading. It improves the prior
stop-the-world implementation to be fully concurrent, which minimizes the class unloading work
done during Final Mark pause. This also enables class unloading for the regular GC cycles by
default, in addition to already enabled class unloading during degenerated and full GC cycles.
This relies heavily on runtime facilities introduced in JDK 12, and therefore not available in
11-shenandoah and 8-shenandoah.
JDK-8235755: Parallel GC Improvements
Parallel GC has adopted the same task management mechanism for scheduling parallel tasks as
other collectors. This might result in significant performance improvements. Because of this
change, the following product flags have been obsoleted: `-XX:BindGCTaskThreadsToCPUs`,
`-XX:UseGCTaskAffinity`, and `-XX:GCTaskTimeStampEntries`.
JDK-8235396: JEP 365: ZGC on Windows
The Z Garbage Collector (ZGC) is now available as an experimental feature on Windows. To
enable it, use the JVM flags `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`. See [JEP 365: ZGC
on Windows](https://openjdk.java.net/jeps/365) for more information.
JDK-8236245: Shenandoah: asynchronous object/region pinning
When dealing with JNI Get*Critical methods, Shenandoah employs object/region pinning, instead
of using the GCLocker. Until now, the inefficient pinning implementation have caused
real-world scalability problems on workloads that use a lot of JNI, for example gzip and
graphics. This was improved, and scalability bottleneck should be resolved. This fix was also
backported to 8-shenandoah and 11-shenandoah.
JDK-8237009: Shenandoah supports JFR Leak Profiler
After the recent improvements in runtime, users should now be able to use JFR Leak Profiler
with Shenandoah GC. This is only available with JDK 14 onwards.
JDK-8234141: JEP 345: NUMA-Aware Memory Allocation for G1
The G1 garbage collector now tries to allocate and keep objects on the same NUMA node in the
young generation across garbage collections. This is similar to Parallel GC NUMA awareness.
G1 attempts to evenly distribute Humongous and Old regions across all available NUMA nodes
using a strict interleave. Placement of objects copied from young to old generation is random.
These new NUMA-Aware Memory Allocation heuristics are automatically enabled by using the
`-XX:+UseNUMA` command line option. See [JEP 345: NUMA-Aware Memory Allocation for
G1](https://openjdk.java.net/jeps/345) for more information.
JDK-8234346: JEP 364: ZGC on macOS
The Z Garbage Collector (ZGC) is now available as an experimental feature on macOS. To enable
it, use the JVM flags `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`. See [JEP 364: ZGC on
macOS](https://openjdk.java.net/jeps/364) for more information.
JDK-8237012: Shenandoah arraycopy improvements
When handling Object[] arraycopy, Shenandoah used to evacuate array elements / fix references
in the destination array after the copy. This is not efficient when multiple copies are done,
as fixups would have to run on every copy. Plus, the fixups in the destination array do not
improve the accesses to the source array.
Unfortunately, this was the only way to deal with arraycopy until the GC API was extended. In
JDK 14 with GC API improvements, Shenandoah is now able to fix up object arrays at source
before the arraycopy, which improves performance and opens up other optimization
opportunities.
JDK-8237016: Epsilon warns about Xms/Xmx/AlwaysPreTouch configuration
Many Epsilon GC users expect low latency, but may not be aware that additional configuration
is needed for GCs to perform well in those conditions. It now warns about
Xms/Xmx/AlwaysPreTouch configuration. These settings are not adjusted automatically, because
doing so would affect startup time. These new warnings can be shunned by overriding the
default logging level with -Xlog:gc=error.
JDK-8233390: JEP 363: Remove the Concurrent Mark and Sweep (CMS) Garbage Collector
The CMS garbage collector has been removed. `-XX:UseConcMarkSweepGC` and aliases `-Xconcgc`
and `-Xnoconcgc` are obsoleted as well as all CMS specific options (too many to list). See
[JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage
Collector](https://openjdk.java.net/jeps/363) for more information.
JDK-8236248: Epsilon does not extend TLABs to max size
Due to a simple implementation bug, Epsilon GC did not extend the size of the issued TLABs to
the max size configured by user, or set by default. This bug might have introduced performance
penalties and was generally confusing during performance analysis. This is now fixed and
backported to 13u and 11u. Users are advised to double-check their performance results before
and after this update.
JDK-8237013: Shenandoah self-fixing barriers
Before this improvement, Shenandoah LRB barrier performance penalty for accessing forwarded
objects involved resolving through the forwarding pointer, until the Update References phase
fixed the affected references. A more efficient implementation ships now, where LRB self-fixes
the forwarded reference on the same code path, eliminating continuous resolves for potentially
hot accesses.
Self-fixing is implemented for C1 and C2 (JDK-8231087), interpreter (JDK-8232992) and runtime
(JDK-8232010) barriers.
JDK-8237011: Shenandoah CAS barriers improvements
Following the Load-Reference-Barriers work in JDK 13 (JDK-8221766), Shenandoah improves CAS
barriers to be more efficient. This may translate to higher performance in heavily concurrent
code that deals with lots of object reference CASes, e.g. with AtomicReference.compareAndSet,
VarHandle.compareAndSet, Unsafe.compareAndSet, etc.
JDK-8234585: JEP 366: Deprecate the ParallelScavenge + SerialOld GC Combination
The ParallelScavenge + SerialOld garbage collector combination has been deprecated. Any use of
the `UseParallelOldGC` command line option, which is used to enable this garbage collection
algorithm combination, will cause a deprecation warning.
The drop-in replacement is to use the ParallelScavenge + ParallelOld garbage collector through
`-XX:+UseParallelGC` on the command line.
See [JEP 366: Deprecate the ParallelScavenge + SerialOld GC
Combination](https://openjdk.java.net/jeps/366) for more information.
JDK-8237010: Shenandoah supports concurrent class unloading
As of JDK 14, Shenandoah GC supports concurrent class unloading. It improves the prior
stop-the-world implementation to be fully concurrent, which minimizes the class unloading work
done during Final Mark pause. This also enables class unloading for the regular GC cycles by
default, in addition to already enabled class unloading during degenerated and full GC cycles.
This relies heavily on runtime facilities introduced in JDK 12, and therefore not available in
11-shenandoah and 8-shenandoah.
JDK-8235755: Parallel GC Improvements
Parallel GC has adopted the same task management mechanism for scheduling parallel tasks as
other collectors. This might result in significant performance improvements. Because of this
change, the following product flags have been obsoleted: `-XX:BindGCTaskThreadsToCPUs`,
`-XX:UseGCTaskAffinity`, and `-XX:GCTaskTimeStampEntries`.
JDK-8235396: JEP 365: ZGC on Windows
The Z Garbage Collector (ZGC) is now available as an experimental feature on Windows. To
enable it, use the JVM flags `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`. See [JEP 365: ZGC
on Windows](https://openjdk.java.net/jeps/365) for more information.
JDK-8236245: Shenandoah: asynchronous object/region pinning
When dealing with JNI Get*Critical methods, Shenandoah employs object/region pinning, instead
of using the GCLocker. Until now, the inefficient pinning implementation have caused
real-world scalability problems on workloads that use a lot of JNI, for example gzip and
graphics. This was improved, and scalability bottleneck should be resolved. This fix was also
backported to 8-shenandoah and 11-shenandoah.
JDK-8237009: Shenandoah supports JFR Leak Profiler
After the recent improvements in runtime, users should now be able to use JFR Leak Profiler
with Shenandoah GC. This is only available with JDK 14 onwards.
JDK-8234141: JEP 345: NUMA-Aware Memory Allocation for G1
The G1 garbage collector now tries to allocate and keep objects on the same NUMA node in the
young generation across garbage collections. This is similar to Parallel GC NUMA awareness.
G1 attempts to evenly distribute Humongous and Old regions across all available NUMA nodes
using a strict interleave. Placement of objects copied from young to old generation is random.
These new NUMA-Aware Memory Allocation heuristics are automatically enabled by using the
`-XX:+UseNUMA` command line option. See [JEP 345: NUMA-Aware Memory Allocation for
G1](https://openjdk.java.net/jeps/345) for more information.
JDK-8234346: JEP 364: ZGC on macOS
The Z Garbage Collector (ZGC) is now available as an experimental feature on macOS. To enable
it, use the JVM flags `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`. See [JEP 364: ZGC on
macOS](https://openjdk.java.net/jeps/364) for more information.
JDK-8237012: Shenandoah arraycopy improvements
When handling Object[] arraycopy, Shenandoah used to evacuate array elements / fix references
in the destination array after the copy. This is not efficient when multiple copies are done,
as fixups would have to run on every copy. Plus, the fixups in the destination array do not
improve the accesses to the source array.
Unfortunately, this was the only way to deal with arraycopy until the GC API was extended. In
JDK 14 with GC API improvements, Shenandoah is now able to fix up object arrays at source
before the arraycopy, which improves performance and opens up other optimization
opportunities.
JDK-8237016: Epsilon warns about Xms/Xmx/AlwaysPreTouch configuration
Many Epsilon GC users expect low latency, but may not be aware that additional configuration
is needed for GCs to perform well in those conditions. It now warns about
Xms/Xmx/AlwaysPreTouch configuration. These settings are not adjusted automatically, because
doing so would affect startup time. These new warnings can be shunned by overriding the
default logging level with -Xlog:gc=error.
JDK-8233390: JEP 363: Remove the Concurrent Mark and Sweep (CMS) Garbage Collector
The CMS garbage collector has been removed. `-XX:UseConcMarkSweepGC` and aliases `-Xconcgc`
and `-Xnoconcgc` are obsoleted as well as all CMS specific options (too many to list). See
[JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage
Collector](https://openjdk.java.net/jeps/363) for more information.
JDK-8236248: Epsilon does not extend TLABs to max size
Due to a simple implementation bug, Epsilon GC did not extend the size of the issued TLABs to
the max size configured by user, or set by default. This bug might have introduced performance
penalties and was generally confusing during performance analysis. This is now fixed and
backported to 13u and 11u. Users are advised to double-check their performance results before
and after this update.
JDK-8237013: Shenandoah self-fixing barriers
Before this improvement, Shenandoah LRB barrier performance penalty for accessing forwarded
objects involved resolving through the forwarding pointer, until the Update References phase
fixed the affected references. A more efficient implementation ships now, where LRB self-fixes
the forwarded reference on the same code path, eliminating continuous resolves for potentially
hot accesses.
Self-fixing is implemented for C1 and C2 (JDK-8231087), interpreter (JDK-8232992) and runtime
(JDK-8232010) barriers.
JDK-8237011: Shenandoah CAS barriers improvements
Following the Load-Reference-Barriers work in JDK 13 (JDK-8221766), Shenandoah improves CAS
barriers to be more efficient. This may translate to higher performance in heavily concurrent
code that deals with lots of object reference CASes, e.g. with AtomicReference.compareAndSet,
VarHandle.compareAndSet, Unsafe.compareAndSet, etc.
JDK-8234585: JEP 366: Deprecate the ParallelScavenge + SerialOld GC Combination
The ParallelScavenge + SerialOld garbage collector combination has been deprecated. Any use of
the `UseParallelOldGC` command line option, which is used to enable this garbage collection
algorithm combination, will cause a deprecation warning.
The drop-in replacement is to use the ParallelScavenge + ParallelOld garbage collector through
`-XX:+UseParallelGC` on the command line.
See [JEP 366: Deprecate the ParallelScavenge + SerialOld GC
Combination](https://openjdk.java.net/jeps/366) for more information.
JDK-8237010: Shenandoah supports concurrent class unloading
As of JDK 14, Shenandoah GC supports concurrent class unloading. It improves the prior
stop-the-world implementation to be fully concurrent, which minimizes the class unloading work
done during Final Mark pause. This also enables class unloading for the regular GC cycles by
default, in addition to already enabled class unloading during degenerated and full GC cycles.
This relies heavily on runtime facilities introduced in JDK 12, and therefore not available in
11-shenandoah and 8-shenandoah.
JDK-8235755: Parallel GC Improvements
Parallel GC has adopted the same task management mechanism for scheduling parallel tasks as
other collectors. This might result in significant performance improvements. Because of this
change, the following product flags have been obsoleted: `-XX:BindGCTaskThreadsToCPUs`,
`-XX:UseGCTaskAffinity`, and `-XX:GCTaskTimeStampEntries`.
JDK-8235396: JEP 365: ZGC on Windows
The Z Garbage Collector (ZGC) is now available as an experimental feature on Windows. To
enable it, use the JVM flags `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`. See [JEP 365: ZGC
on Windows](https://openjdk.java.net/jeps/365) for more information.
JDK-8236245: Shenandoah: asynchronous object/region pinning
When dealing with JNI Get*Critical methods, Shenandoah employs object/region pinning, instead
of using the GCLocker. Until now, the inefficient pinning implementation have caused
real-world scalability problems on workloads that use a lot of JNI, for example gzip and
graphics. This was improved, and scalability bottleneck should be resolved. This fix was also
backported to 8-shenandoah and 11-shenandoah.
JDK-8237009: Shenandoah supports JFR Leak Profiler
After the recent improvements in runtime, users should now be able to use JFR Leak Profiler
with Shenandoah GC. This is only available with JDK 14 onwards.
JDK-8234141: JEP 345: NUMA-Aware Memory Allocation for G1
The G1 garbage collector now tries to allocate and keep objects on the same NUMA node in the
young generation across garbage collections. This is similar to Parallel GC NUMA awareness.
G1 attempts to evenly distribute Humongous and Old regions across all available NUMA nodes
using a strict interleave. Placement of objects copied from young to old generation is random.
These new NUMA-Aware Memory Allocation heuristics are automatically enabled by using the
`-XX:+UseNUMA` command line option. See [JEP 345: NUMA-Aware Memory Allocation for
G1](https://openjdk.java.net/jeps/345) for more information.
JDK-8234346: JEP 364: ZGC on macOS
The Z Garbage Collector (ZGC) is now available as an experimental feature on macOS. To enable
it, use the JVM flags `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`. See [JEP 364: ZGC on
macOS](https://openjdk.java.net/jeps/364) for more information.
JDK-8237012: Shenandoah arraycopy improvements
When handling Object[] arraycopy, Shenandoah used to evacuate array elements / fix references
in the destination array after the copy. This is not efficient when multiple copies are done,
as fixups would have to run on every copy. Plus, the fixups in the destination array do not
improve the accesses to the source array.
Unfortunately, this was the only way to deal with arraycopy until the GC API was extended. In
JDK 14 with GC API improvements, Shenandoah is now able to fix up object arrays at source
before the arraycopy, which improves performance and opens up other optimization
opportunities.
JDK-8237016: Epsilon warns about Xms/Xmx/AlwaysPreTouch configuration
Many Epsilon GC users expect low latency, but may not be aware that additional configuration
is needed for GCs to perform well in those conditions. It now warns about
Xms/Xmx/AlwaysPreTouch configuration. These settings are not adjusted automatically, because
doing so would affect startup time. These new warnings can be shunned by overriding the
default logging level with -Xlog:gc=error.
JDK-8233390: JEP 363: Remove the Concurrent Mark and Sweep (CMS) Garbage Collector
The CMS garbage collector has been removed. `-XX:UseConcMarkSweepGC` and aliases `-Xconcgc`
and `-Xnoconcgc` are obsoleted as well as all CMS specific options (too many to list). See
[JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage
Collector](https://openjdk.java.net/jeps/363) for more information.
JDK-8236248: Epsilon does not extend TLABs to max size
Due to a simple implementation bug, Epsilon GC did not extend the size of the issued TLABs to
the max size configured by user, or set by default. This bug might have introduced performance
penalties and was generally confusing during performance analysis. This is now fixed and
backported to 13u and 11u. Users are advised to double-check their performance results before
and after this update.
JDK-8237013: Shenandoah self-fixing barriers
Before this improvement, Shenandoah LRB barrier performance penalty for accessing forwarded
objects involved resolving through the forwarding pointer, until the Update References phase
fixed the affected references. A more efficient implementation ships now, where LRB self-fixes
the forwarded reference on the same code path, eliminating continuous resolves for potentially
hot accesses.
Self-fixing is implemented for C1 and C2 (JDK-8231087), interpreter (JDK-8232992) and runtime
(JDK-8232010) barriers.
JDK-8237011: Shenandoah CAS barriers improvements
Following the Load-Reference-Barriers work in JDK 13 (JDK-8221766), Shenandoah improves CAS
barriers to be more efficient. This may translate to higher performance in heavily concurrent
code that deals with lots of object reference CASes, e.g. with AtomicReference.compareAndSet,
VarHandle.compareAndSet, Unsafe.compareAndSet, etc.
JDK-8234585: JEP 366: Deprecate the ParallelScavenge + SerialOld GC Combination
The ParallelScavenge + SerialOld garbage collector combination has been deprecated. Any use of
the `UseParallelOldGC` command line option, which is used to enable this garbage collection
algorithm combination, will cause a deprecation warning.
The drop-in replacement is to use the ParallelScavenge + ParallelOld garbage collector through
`-XX:+UseParallelGC` on the command line.
See [JEP 366: Deprecate the ParallelScavenge + SerialOld GC
Combination](https://openjdk.java.net/jeps/366) for more information.
JDK-8237010: Shenandoah supports concurrent class unloading
As of JDK 14, Shenandoah GC supports concurrent class unloading. It improves the prior
stop-the-world implementation to be fully concurrent, which minimizes the class unloading work
done during Final Mark pause. This also enables class unloading for the regular GC cycles by
default, in addition to already enabled class unloading during degenerated and full GC cycles.
This relies heavily on runtime facilities introduced in JDK 12, and therefore not available in
11-shenandoah and 8-shenandoah.
JDK-8235755: Parallel GC Improvements
Parallel GC has adopted the same task management mechanism for scheduling parallel tasks as
other collectors. This might result in significant performance improvements. Because of this
change, the following product flags have been obsoleted: `-XX:BindGCTaskThreadsToCPUs`,
`-XX:UseGCTaskAffinity`, and `-XX:GCTaskTimeStampEntries`.
JDK-8235396: JEP 365: ZGC on Windows
The Z Garbage Collector (ZGC) is now available as an experimental feature on Windows. To
enable it, use the JVM flags `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`. See [JEP 365: ZGC
on Windows](https://openjdk.java.net/jeps/365) for more information.
JDK-8236245: Shenandoah: asynchronous object/region pinning
When dealing with JNI Get*Critical methods, Shenandoah employs object/region pinning, instead
of using the GCLocker. Until now, the inefficient pinning implementation have caused
real-world scalability problems on workloads that use a lot of JNI, for example gzip and
graphics. This was improved, and scalability bottleneck should be resolved. This fix was also
backported to 8-shenandoah and 11-shenandoah.
JDK-8237009: Shenandoah supports JFR Leak Profiler
After the recent improvements in runtime, users should now be able to use JFR Leak Profiler
with Shenandoah GC. This is only available with JDK 14 onwards.
JDK-8234141: JEP 345: NUMA-Aware Memory Allocation for G1
The G1 garbage collector now tries to allocate and keep objects on the same NUMA node in the
young generation across garbage collections. This is similar to Parallel GC NUMA awareness.
G1 attempts to evenly distribute Humongous and Old regions across all available NUMA nodes
using a strict interleave. Placement of objects copied from young to old generation is random.
These new NUMA-Aware Memory Allocation heuristics are automatically enabled by using the
`-XX:+UseNUMA` command line option. See [JEP 345: NUMA-Aware Memory Allocation for
G1](https://openjdk.java.net/jeps/345) for more information.
JDK-8234346: JEP 364: ZGC on macOS
The Z Garbage Collector (ZGC) is now available as an experimental feature on macOS. To enable
it, use the JVM flags `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`. See [JEP 364: ZGC on
macOS](https://openjdk.java.net/jeps/364) for more information.
JDK-8237012: Shenandoah arraycopy improvements
When handling Object[] arraycopy, Shenandoah used to evacuate array elements / fix references
in the destination array after the copy. This is not efficient when multiple copies are done,
as fixups would have to run on every copy. Plus, the fixups in the destination array do not
improve the accesses to the source array.
Unfortunately, this was the only way to deal with arraycopy until the GC API was extended. In
JDK 14 with GC API improvements, Shenandoah is now able to fix up object arrays at source
before the arraycopy, which improves performance and opens up other optimization
opportunities.
JDK-8237016: Epsilon warns about Xms/Xmx/AlwaysPreTouch configuration
Many Epsilon GC users expect low latency, but may not be aware that additional configuration
is needed for GCs to perform well in those conditions. It now warns about
Xms/Xmx/AlwaysPreTouch configuration. These settings are not adjusted automatically, because
doing so would affect startup time. These new warnings can be shunned by overriding the
default logging level with -Xlog:gc=error.
JDK-8233390: JEP 363: Remove the Concurrent Mark and Sweep (CMS) Garbage Collector
The CMS garbage collector has been removed. `-XX:UseConcMarkSweepGC` and aliases `-Xconcgc`
and `-Xnoconcgc` are obsoleted as well as all CMS specific options (too many to list). See
[JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage
Collector](https://openjdk.java.net/jeps/363) for more information.
JDK-8236248: Epsilon does not extend TLABs to max size
Due to a simple implementation bug, Epsilon GC did not extend the size of the issued TLABs to
the max size configured by user, or set by default. This bug might have introduced performance
penalties and was generally confusing during performance analysis. This is now fixed and
backported to 13u and 11u. Users are advised to double-check their performance results before
and after this update.
JDK-8237013: Shenandoah self-fixing barriers
Before this improvement, Shenandoah LRB barrier performance penalty for accessing forwarded
objects involved resolving through the forwarding pointer, until the Update References phase
fixed the affected references. A more efficient implementation ships now, where LRB self-fixes
the forwarded reference on the same code path, eliminating continuous resolves for potentially
hot accesses.
Self-fixing is implemented for C1 and C2 (JDK-8231087), interpreter (JDK-8232992) and runtime
(JDK-8232010) barriers.
JDK-8237011: Shenandoah CAS barriers improvements
Following the Load-Reference-Barriers work in JDK 13 (JDK-8221766), Shenandoah improves CAS
barriers to be more efficient. This may translate to higher performance in heavily concurrent
code that deals with lots of object reference CASes, e.g. with AtomicReference.compareAndSet,
VarHandle.compareAndSet, Unsafe.compareAndSet, etc.
JDK-8234585: JEP 366: Deprecate the ParallelScavenge + SerialOld GC Combination
The ParallelScavenge + SerialOld garbage collector combination has been deprecated. Any use of
the `UseParallelOldGC` command line option, which is used to enable this garbage collection
algorithm combination, will cause a deprecation warning.
The drop-in replacement is to use the ParallelScavenge + ParallelOld garbage collector through
`-XX:+UseParallelGC` on the command line.
See [JEP 366: Deprecate the ParallelScavenge + SerialOld GC
Combination](https://openjdk.java.net/jeps/366) for more information.
JDK-8237010: Shenandoah supports concurrent class unloading
As of JDK 14, Shenandoah GC supports concurrent class unloading. It improves the prior
stop-the-world implementation to be fully concurrent, which minimizes the class unloading work
done during Final Mark pause. This also enables class unloading for the regular GC cycles by
default, in addition to already enabled class unloading during degenerated and full GC cycles.
This relies heavily on runtime facilities introduced in JDK 12, and therefore not available in
11-shenandoah and 8-shenandoah.
JDK-8235755: Parallel GC Improvements
Parallel GC has adopted the same task management mechanism for scheduling parallel tasks as
other collectors. This might result in significant performance improvements. Because of this
change, the following product flags have been obsoleted: `-XX:BindGCTaskThreadsToCPUs`,
`-XX:UseGCTaskAffinity`, and `-XX:GCTaskTimeStampEntries`.
JDK-8235396: JEP 365: ZGC on Windows
The Z Garbage Collector (ZGC) is now available as an experimental feature on Windows. To
enable it, use the JVM flags `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`. See [JEP 365: ZGC
on Windows](https://openjdk.java.net/jeps/365) for more information.
JDK-8236245: Shenandoah: asynchronous object/region pinning
When dealing with JNI Get*Critical methods, Shenandoah employs object/region pinning, instead
of using the GCLocker. Until now, the inefficient pinning implementation have caused
real-world scalability problems on workloads that use a lot of JNI, for example gzip and
graphics. This was improved, and scalability bottleneck should be resolved. This fix was also
backported to 8-shenandoah and 11-shenandoah.
JDK-8237009: Shenandoah supports JFR Leak Profiler
After the recent improvements in runtime, users should now be able to use JFR Leak Profiler
with Shenandoah GC. This is only available with JDK 14 onwards.
JDK-8234141: JEP 345: NUMA-Aware Memory Allocation for G1
The G1 garbage collector now tries to allocate and keep objects on the same NUMA node in the
young generation across garbage collections. This is similar to Parallel GC NUMA awareness.
G1 attempts to evenly distribute Humongous and Old regions across all available NUMA nodes
using a strict interleave. Placement of objects copied from young to old generation is random.
These new NUMA-Aware Memory Allocation heuristics are automatically enabled by using the
`-XX:+UseNUMA` command line option. See [JEP 345: NUMA-Aware Memory Allocation for
G1](https://openjdk.java.net/jeps/345) for more information.
JDK-8234346: JEP 364: ZGC on macOS
The Z Garbage Collector (ZGC) is now available as an experimental feature on macOS. To enable
it, use the JVM flags `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`. See [JEP 364: ZGC on
macOS](https://openjdk.java.net/jeps/364) for more information.
JDK-8237012: Shenandoah arraycopy improvements
When handling Object[] arraycopy, Shenandoah used to evacuate array elements / fix references
in the destination array after the copy. This is not efficient when multiple copies are done,
as fixups would have to run on every copy. Plus, the fixups in the destination array do not
improve the accesses to the source array.
Unfortunately, this was the only way to deal with arraycopy until the GC API was extended. In
JDK 14 with GC API improvements, Shenandoah is now able to fix up object arrays at source
before the arraycopy, which improves performance and opens up other optimization
opportunities.
JDK-8237016: Epsilon warns about Xms/Xmx/AlwaysPreTouch configuration
Many Epsilon GC users expect low latency, but may not be aware that additional configuration
is needed for GCs to perform well in those conditions. It now warns about
Xms/Xmx/AlwaysPreTouch configuration. These settings are not adjusted automatically, because
doing so would affect startup time. These new warnings can be shunned by overriding the
default logging level with -Xlog:gc=error.
JDK-8233390: JEP 363: Remove the Concurrent Mark and Sweep (CMS) Garbage Collector
The CMS garbage collector has been removed. `-XX:UseConcMarkSweepGC` and aliases `-Xconcgc`
and `-Xnoconcgc` are obsoleted as well as all CMS specific options (too many to list). See
[JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage
Collector](https://openjdk.java.net/jeps/363) for more information.
JDK-8236248: Epsilon does not extend TLABs to max size
Due to a simple implementation bug, Epsilon GC did not extend the size of the issued TLABs to
the max size configured by user, or set by default. This bug might have introduced performance
penalties and was generally confusing during performance analysis. This is now fixed and
backported to 13u and 11u. Users are advised to double-check their performance results before
and after this update.
JDK-8237013: Shenandoah self-fixing barriers
Before this improvement, Shenandoah LRB barrier performance penalty for accessing forwarded
objects involved resolving through the forwarding pointer, until the Update References phase
fixed the affected references. A more efficient implementation ships now, where LRB self-fixes
the forwarded reference on the same code path, eliminating continuous resolves for potentially
hot accesses.
Self-fixing is implemented for C1 and C2 (JDK-8231087), interpreter (JDK-8232992) and runtime
(JDK-8232010) barriers.
JDK-8237011: Shenandoah CAS barriers improvements
Following the Load-Reference-Barriers work in JDK 13 (JDK-8221766), Shenandoah improves CAS
barriers to be more efficient. This may translate to higher performance in heavily concurrent
code that deals with lots of object reference CASes, e.g. with AtomicReference.compareAndSet,
VarHandle.compareAndSet, Unsafe.compareAndSet, etc.
JDK-8234585: JEP 366: Deprecate the ParallelScavenge + SerialOld GC Combination
The ParallelScavenge + SerialOld garbage collector combination has been deprecated. Any use of
the `UseParallelOldGC` command line option, which is used to enable this garbage collection
algorithm combination, will cause a deprecation warning.
The drop-in replacement is to use the ParallelScavenge + ParallelOld garbage collector through
`-XX:+UseParallelGC` on the command line.
See [JEP 366: Deprecate the ParallelScavenge + SerialOld GC
Combination](https://openjdk.java.net/jeps/366) for more information.
JDK-8237010: Shenandoah supports concurrent class unloading
As of JDK 14, Shenandoah GC supports concurrent class unloading. It improves the prior
stop-the-world implementation to be fully concurrent, which minimizes the class unloading work
done during Final Mark pause. This also enables class unloading for the regular GC cycles by
default, in addition to already enabled class unloading during degenerated and full GC cycles.
This relies heavily on runtime facilities introduced in JDK 12, and therefore not available in
11-shenandoah and 8-shenandoah.
JDK-8235755: Parallel GC Improvements
Parallel GC has adopted the same task management mechanism for scheduling parallel tasks as
other collectors. This might result in significant performance improvements. Because of this
change, the following product flags have been obsoleted: `-XX:BindGCTaskThreadsToCPUs`,
`-XX:UseGCTaskAffinity`, and `-XX:GCTaskTimeStampEntries`.
JDK-8235396: JEP 365: ZGC on Windows
The Z Garbage Collector (ZGC) is now available as an experimental feature on Windows. To
enable it, use the JVM flags `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`. See [JEP 365: ZGC
on Windows](https://openjdk.java.net/jeps/365) for more information.
JDK-8236245: Shenandoah: asynchronous object/region pinning
When dealing with JNI Get*Critical methods, Shenandoah employs object/region pinning, instead
of using the GCLocker. Until now, the inefficient pinning implementation have caused
real-world scalability problems on workloads that use a lot of JNI, for example gzip and
graphics. This was improved, and scalability bottleneck should be resolved. This fix was also
backported to 8-shenandoah and 11-shenandoah.
JDK-8237009: Shenandoah supports JFR Leak Profiler
After the recent improvements in runtime, users should now be able to use JFR Leak Profiler
with Shenandoah GC. This is only available with JDK 14 onwards.
JDK-8234141: JEP 345: NUMA-Aware Memory Allocation for G1
The G1 garbage collector now tries to allocate and keep objects on the same NUMA node in the
young generation across garbage collections. This is similar to Parallel GC NUMA awareness.
G1 attempts to evenly distribute Humongous and Old regions across all available NUMA nodes
using a strict interleave. Placement of objects copied from young to old generation is random.
These new NUMA-Aware Memory Allocation heuristics are automatically enabled by using the
`-XX:+UseNUMA` command line option. See [JEP 345: NUMA-Aware Memory Allocation for
G1](https://openjdk.java.net/jeps/345) for more information.
JDK-8234346: JEP 364: ZGC on macOS
The Z Garbage Collector (ZGC) is now available as an experimental feature on macOS. To enable
it, use the JVM flags `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`. See [JEP 364: ZGC on
macOS](https://openjdk.java.net/jeps/364) for more information.
JDK-8237012: Shenandoah arraycopy improvements
When handling Object[] arraycopy, Shenandoah used to evacuate array elements / fix references
in the destination array after the copy. This is not efficient when multiple copies are done,
as fixups would have to run on every copy. Plus, the fixups in the destination array do not
improve the accesses to the source array.
Unfortunately, this was the only way to deal with arraycopy until the GC API was extended. In
JDK 14 with GC API improvements, Shenandoah is now able to fix up object arrays at source
before the arraycopy, which improves performance and opens up other optimization
opportunities.
JDK-8237016: Epsilon warns about Xms/Xmx/AlwaysPreTouch configuration
Many Epsilon GC users expect low latency, but may not be aware that additional configuration
is needed for GCs to perform well in those conditions. It now warns about
Xms/Xmx/AlwaysPreTouch configuration. These settings are not adjusted automatically, because
doing so would affect startup time. These new warnings can be shunned by overriding the
default logging level with -Xlog:gc=error.
JDK-8233390: JEP 363: Remove the Concurrent Mark and Sweep (CMS) Garbage Collector
The CMS garbage collector has been removed. `-XX:UseConcMarkSweepGC` and aliases `-Xconcgc`
and `-Xnoconcgc` are obsoleted as well as all CMS specific options (too many to list). See
[JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage
Collector](https://openjdk.java.net/jeps/363) for more information.
JDK-8236248: Epsilon does not extend TLABs to max size
Due to a simple implementation bug, Epsilon GC did not extend the size of the issued TLABs to
the max size configured by user, or set by default. This bug might have introduced performance
penalties and was generally confusing during performance analysis. This is now fixed and
backported to 13u and 11u. Users are advised to double-check their performance results before
and after this update.
JDK-8237013: Shenandoah self-fixing barriers
Before this improvement, Shenandoah LRB barrier performance penalty for accessing forwarded
objects involved resolving through the forwarding pointer, until the Update References phase
fixed the affected references. A more efficient implementation ships now, where LRB self-fixes
the forwarded reference on the same code path, eliminating continuous resolves for potentially
hot accesses.
Self-fixing is implemented for C1 and C2 (JDK-8231087), interpreter (JDK-8232992) and runtime
(JDK-8232010) barriers.
JDK-8237011: Shenandoah CAS barriers improvements
Following the Load-Reference-Barriers work in JDK 13 (JDK-8221766), Shenandoah improves CAS
barriers to be more efficient. This may translate to higher performance in heavily concurrent
code that deals with lots of object reference CASes, e.g. with AtomicReference.compareAndSet,
VarHandle.compareAndSet, Unsafe.compareAndSet, etc.
JDK-8234585: JEP 366: Deprecate the ParallelScavenge + SerialOld GC Combination
The ParallelScavenge + SerialOld garbage collector combination has been deprecated. Any use of
the `UseParallelOldGC` command line option, which is used to enable this garbage collection
algorithm combination, will cause a deprecation warning.
The drop-in replacement is to use the ParallelScavenge + ParallelOld garbage collector through
`-XX:+UseParallelGC` on the command line.
See [JEP 366: Deprecate the ParallelScavenge + SerialOld GC
Combination](https://openjdk.java.net/jeps/366) for more information.
JDK-8237010: Shenandoah supports concurrent class unloading
As of JDK 14, Shenandoah GC supports concurrent class unloading. It improves the prior
stop-the-world implementation to be fully concurrent, which minimizes the class unloading work
done during Final Mark pause. This also enables class unloading for the regular GC cycles by
default, in addition to already enabled class unloading during degenerated and full GC cycles.
This relies heavily on runtime facilities introduced in JDK 12, and therefore not available in
11-shenandoah and 8-shenandoah.
JDK-8235755: Parallel GC Improvements
Parallel GC has adopted the same task management mechanism for scheduling parallel tasks as
other collectors. This might result in significant performance improvements. Because of this
change, the following product flags have been obsoleted: `-XX:BindGCTaskThreadsToCPUs`,
`-XX:UseGCTaskAffinity`, and `-XX:GCTaskTimeStampEntries`.
JDK-8235396: JEP 365: ZGC on Windows
The Z Garbage Collector (ZGC) is now available as an experimental feature on Windows. To
enable it, use the JVM flags `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`. See [JEP 365: ZGC
on Windows](https://openjdk.java.net/jeps/365) for more information.
JDK-8236245: Shenandoah: asynchronous object/region pinning
When dealing with JNI Get*Critical methods, Shenandoah employs object/region pinning, instead
of using the GCLocker. Until now, the inefficient pinning implementation have caused
real-world scalability problems on workloads that use a lot of JNI, for example gzip and
graphics. This was improved, and scalability bottleneck should be resolved. This fix was also
backported to 8-shenandoah and 11-shenandoah.
JDK-8237009: Shenandoah supports JFR Leak Profiler
After the recent improvements in runtime, users should now be able to use JFR Leak Profiler
with Shenandoah GC. This is only available with JDK 14 onwards.
JDK-8234141: JEP 345: NUMA-Aware Memory Allocation for G1
The G1 garbage collector now tries to allocate and keep objects on the same NUMA node in the
young generation across garbage collections. This is similar to Parallel GC NUMA awareness.
G1 attempts to evenly distribute Humongous and Old regions across all available NUMA nodes
using a strict interleave. Placement of objects copied from young to old generation is random.
These new NUMA-Aware Memory Allocation heuristics are automatically enabled by using the
`-XX:+UseNUMA` command line option. See [JEP 345: NUMA-Aware Memory Allocation for
G1](https://openjdk.java.net/jeps/345) for more information.
JDK-8234346: JEP 364: ZGC on macOS
The Z Garbage Collector (ZGC) is now available as an experimental feature on macOS. To enable
it, use the JVM flags `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`. See [JEP 364: ZGC on
macOS](https://openjdk.java.net/jeps/364) for more information.
JDK-8237012: Shenandoah arraycopy improvements
When handling Object[] arraycopy, Shenandoah used to evacuate array elements / fix references
in the destination array after the copy. This is not efficient when multiple copies are done,
as fixups would have to run on every copy. Plus, the fixups in the destination array do not
improve the accesses to the source array.
Unfortunately, this was the only way to deal with arraycopy until the GC API was extended. In
JDK 14 with GC API improvements, Shenandoah is now able to fix up object arrays at source
before the arraycopy, which improves performance and opens up other optimization
opportunities.
JDK-8237016: Epsilon warns about Xms/Xmx/AlwaysPreTouch configuration
Many Epsilon GC users expect low latency, but may not be aware that additional configuration
is needed for GCs to perform well in those conditions. It now warns about
Xms/Xmx/AlwaysPreTouch configuration. These settings are not adjusted automatically, because
doing so would affect startup time. These new warnings can be shunned by overriding the
default logging level with -Xlog:gc=error.
JDK-8233390: JEP 363: Remove the Concurrent Mark and Sweep (CMS) Garbage Collector
The CMS garbage collector has been removed. `-XX:UseConcMarkSweepGC` and aliases `-Xconcgc`
and `-Xnoconcgc` are obsoleted as well as all CMS specific options (too many to list). See
[JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage
Collector](https://openjdk.java.net/jeps/363) for more information.
core-svc/java.lang.management:
JDK-8236876: OperatingSystemMXBean Methods Inside a Container Return Container Specific Data
When executing in a container, or other virtualized operating environment, the following
`OperatingSystemMXBean` methods in this release return container specific information, if
available. Otherwise, they return host specific data:
- `getFreePhysicalMemorySize()` - `getTotalPhysicalMemorySize()` - `getFreeSwapSpaceSize()` -
`getTotalSwapSpaceSize()` - `getSystemCpuLoad()`
ALL FIXED ISSUES, BY COMPONENT AND PRIORITY:
:
(P3) JDK-8231554: JEP 362: Deprecate the Solaris and SPARC Ports
client-libs:
(P3) JDK-8225372: accessibility errors in tables in java.desktop files
(P3) JDK-8235245: tiff_metadata.html has invalid HTML structure: misplaced element
(P3) JDK-8231144: Wrap contents of plain HTML files into contentContainer
(P4) JDK-8227737: avoid implicit-function-declaration on AIX
(P4) JDK-8231027: Correct typos
(P4) JDK-8229896: Delete an unused code in the BufferedContext
(P4) JDK-8233910: java/awt/ColorClass/AlphaColorTest.java is failing intermittently in nightly lnux-x64 system
(P4) JDK-8231991: Mouse wheel change focus on awt/swing windows
(P4) JDK-8232225: Rework the fix for JDK-8071483
client-libs/2d:
(P2) JDK-8233097: Fontmetrics for large Fonts has zero width
(P2) JDK-8232154: Update Mesa 3-D Headers to version 19.2.1
(P2) JDK-8229800: WindowsServerCore 1809 does not provide d2d1.dll library required by awt.dll
(P3) JDK-8232200: [macos 10.15] Windows in fullscreen tests jumps around the screen
(P3) JDK-8146238: [macosx] Java2D Queue Flusher crash on OSX after switching between user accounts
(P3) JDK-8232381: add result NULL-checking to freetypeScaler.c
(P3) JDK-8230769: BufImg_SetupICM add ReleasePrimitiveArrayCritical call in early return
(P3) JDK-8234769: Duplicate attribution in freetype.md
(P3) JDK-8214481: freetype path does not disable TrueType hinting with AA+FM hints
(P3) JDK-8223558: Java does not render Myanmar script correctly
(P3) JDK-8234323: NULL-check return value of SurfaceData_InitOps on macosx
(P3) JDK-8228711: Path rendered incorrectly when it goes outside the clipping region
(P3) JDK-8222108: Reduce minRefreshTime for updating remote printer list on Windows
(P3) JDK-8234398: Replace ID2D1Factory::GetDesktopDpi with GetDeviceCaps
(P3) JDK-8230728: Thin stroked shapes are not rendered if affine transform has flip bit
(P3) JDK-8227324: Upgrade to freetype 2.10.1
(P3) JDK-8209113: Use WeakReference for lastFontStrike for created Fonts
(P3) JDK-8235547: Video memory leak in the OGL pipeline on macOS
(P4) JDK-8231335: [macos] Delete unused and partly implemented JOGL/Java2D bridge
(P4) JDK-8210058: Algorithmic Italic font leans opposite angle in Printing
(P4) JDK-8220074: Clean up GCC 8.3 errors in LittleCMS
(P4) JDK-8228676: Cleanup the native code related to fonts on Unix
(P4) JDK-8234325: Delete unused vsync related code from the OGL pipeline on macOS
(P4) JDK-8227441: Enhance logging when reading the fontconfig info file
(P4) JDK-8233202: exclude javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java
(P4) JDK-8175984: ICC_Profile has un-needed, not-empty finalize method
(P4) JDK-8224171: The cleanup multi-font related code in the XFontPeer
(P4) JDK-8234784: Update jpeg.md to reflect code used by JDK
client-libs/demo:
(P5) JDK-6573239: Typo in jfc text file
client-libs/java.awt:
(P2) JDK-8230869: [macos 10.15] The String "X Y Z" was not set to application's icon in the taskbar
(P2) JDK-8234522: [macos] Crash with use of native file dialog
(P2) JDK-8213119: [macos] java/awt/GraphicsDevice/CheckDisplayModes.java fails
(P2) JDK-8231336: Corrupted option dialog in JTHarness with JDK14b13
(P2) JDK-8230597: Update GIFlib library to the 5.2.1
(P3) JDK-8230873: [AIX] GUI app does not work with UTF-8 locale on minimum software requirements
(P3) JDK-8232433: [macos 10.15] java/awt/Window/LocationAtScreenCorner/LocationAtScreenCorner.java may fail
(P3) JDK-8231438: [macOS] Dark mode for the desktop is not supported
(P3) JDK-8229810: [macos] NullPointerException getting bounds of GraphicsConfiguration
(P3) JDK-8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores system settings
(P3) JDK-8235620: Broken merge between JDK-8006406 and JDK-8003559
(P3) JDK-8231445: check ZALLOC return values in awt coding
(P3) JDK-8225101: Crash at sun.awt.X11.XlibWrapper.XkbGetUpdatedMap when change keybord map
(P3) JDK-8234786: Fix for JDK-8214578 breaks OS X 10.12 compatibility
(P3) JDK-8233657: Intermittent NPE in Component.validate()
(P3) JDK-8230782: Robot.createScreenCapture() fails if “awt.robot.gtk” is set to false
(P3) JDK-8234107: Several AWT modal dialog tests failing on Linux after JDK-8231991
(P4) JDK-8229515: [macos] access to window property of NSView on wrong thread
(P4) JDK-7124404: [macosx] no awt.multiClickInterval desktop property
(P4) JDK-8228468: awt_Robot.c : format string contains 0 within the string body
(P4) JDK-8230480: check malloc/calloc results in java.desktop
(P4) JDK-8230900: missing ReleaseStringUTFChars in java.desktop native code
(P4) JDK-8231334: Suppress warnings on non-serializable instance fields in client libs serializable classes
(P4) JDK-8232078: Suppress warnings on non-serializable non-transient instance fields in java.datatransfer
(P4) JDK-8233707: systemScale.cpp could not compile with VS2019
(P4) JDK-8234137: The "AutoTestOnTop.java" test may run external applications
client-libs/javax.accessibility:
(P3) JDK-4949105: Access Bridge lacks html tags parsing
(P3) JDK-8236044: Create jdk_accessibility test group
(P4) JDK-8225805: Java Access Bridge does not close the logger
client-libs/javax.swing:
(P1) JDK-8235815: Build fails with error: no "alt" attribute for image
(P2) JDK-8236953: [macos] JavaFX SwingNode is not rendered on macOS
(P2) JDK-8230235: Rendering HTML with empty img attribute and documentBaseKey cause Exception
(P3) JDK-8226892: ActionListeners on JRadioButtons don't get notified when selection is changed with arrow keys
(P3) JDK-8227607: Broken external links in java.desktop
(P3) JDK-8190763: Class cast exception on (CompoundEdit) UndoableEditEvent.getEdit()
(P3) JDK-8225505: ctrl-F1 does not show the tooltip of a menu item (JMenuItems)
(P3) JDK-8223158: Docked MacBook cannot start any Java Swing applications
(P3) JDK-8226513: JEditorPane is shown with incorrect size
(P3) JDK-8193544: Regression automated test '/open/test/jdk/javax/swing/JDialog/Transparency/TransparencyTest.java' fails
(P4) JDK-8234386: [macos] NPE was thrown at expanding Choice from maximized frame
(P4) JDK-8042383: [TEST_BUG] Test javax/swing/plaf/basic/BasicMenuUI/4983388/bug4983388.java fails with shortcuts on menus do not work
(P4) JDK-8228368: avoid incompatible pointer to integer conversion initializing gint in gtk2_interface
(P4) JDK-8228479: Correct the format of ColorChooserDemoTest
(P4) JDK-8196467: javax/swing/JInternalFrame/Test6325652.java fails
(P4) JDK-7124307: JSpinner and changing value by mouse
(P4) JDK-8235744: PIT: test/jdk/javax/swing/text/html/TestJLabelWithHTMLText.java times out in linux-x64
(P4) JDK-8194944: Regression automated test 'open/test/jdk/javax/swing/JInternalFrame/8145896/TestJInternalFrameMaximize.java' fails
(P4) JDK-8221312: test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java failed
core-libs:
(P2) JDK-8235837: Memory access API refinements
(P2) JDK-8236779: static field in implementation class erroneously leaking in memory access javadoc
(P3) JDK-8236769: Clarify javadoc of memory access API
(P3) JDK-8234049: Implementation of Memory Access API (Incubator)
(P3) JDK-8228501: java_props_macosx.c - provide missing CFRelease for CFLocaleCopyCurrent
(P3) JDK-8237348: Javadoc of MemorySegment::allocateNative should state that memory is zero-initialized
(P3) JDK-8236634: Memory Access API tests fail on 32-bit
(P3) JDK-8214546: Start of release updates for JDK 14
(P3) JDK-8225320: Umbrella: JDK 14 terminal deprecations
(P4) JDK-8215361: (doc) Cleanup package-info markup - smartcardio, java.sql, java.sql.rowset
(P4) JDK-8226468: [aix] loadquery failed error reported
(P4) JDK-8220348: [ntintel] asserts about copying unaligned array
(P4) JDK-8234147: Avoid looking up standard charsets in core libraries
(P4) JDK-8211360: Change #if DEF to #if defined(DEF)
(P4) JDK-8224974: Implement JEP 352
(P4) JDK-8231663: Incorrect GPL header in some RMI/SQL package-info.java files
(P4) JDK-8227446: JEP 370: Foreign-Memory Access API (Incubator)
(P4) JDK-8230734: Remove default constructors from java.compiler
(P4) JDK-8234335: Remove line break in class declaration in java.base
(P4) JDK-8230648: Replace @exception tag with @throws in java.base
(P4) JDK-8231186: Replace html tag foo with javadoc tag {@code foo} in java.base
(P4) JDK-8226831: Use Objects.equals() when appropriate
(P5) JDK-8231859: Extra dash after the exception name in @throws clause of javadoc
(P5) JDK-8152467: remove uses of anachronistic array declarations for method return type
core-libs/java.io:
(P2) JDK-8228392: Backout incorrect change done by JDK-8067801
(P3) JDK-8237186: Fix typo in copyright header of java/io/Reader/TransferTo.java
(P3) JDK-8229333: java/io/File/SetLastModified.java timed out
(P3) JDK-8235668: LineNumberReader#getLineNumber() returns wrong line number (one fewer) in Lucene test
(P3) JDK-8234781: Update description of InvalidClassException to include more conditions
(P4) JDK-8230681: Add @since tag to java.io.Serial
(P4) JDK-8229022: BufferedReader performance can be improved by using StringBuilder
(P4) JDK-8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument
(P4) JDK-8067801: Enforce null check for underlying I/O streams
(P4) JDK-8179320: File.getUsableSpace() returns a negative number on very large file system
(P4) JDK-8228204: Fix for JDK-8067801 breaks java/io/NegativeInitSize.java
(P4) JDK-8232168: Fix non wide char canonicalization on Windows
(P4) JDK-8229899: java.io.File.isInvalid() is racy
(P4) JDK-8078891: java.io.SequenceInputStream.close is not atomic and not idempotent
(P4) JDK-8131664: Javadoc for PrintStream is now incorrect
(P4) JDK-8073213: javadoc of PushbackInputStream methods should specify NullPointerExceptions
(P4) JDK-8230342: LineNumberReader.getLineNumber() returns inconsistent results after EOF
(P4) JDK-8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause
(P4) JDK-8228338: tools/pack200/TimeStamp.java fails with NullPointerException
core-libs/java.io:serialization:
(P2) JDK-8234782: Discuss evolution of records in serialization spec
(P2) JDK-8237019: Serialization Specification changes for Records
(P3) JDK-8237651: Clarify initialization of jdk.serialFilter
(P3) JDK-8235531: Update record serialization migration tests to not use hard coded source versions
(P3) JDK-8235514: Update record serialization tests to not use hard coded source versions
(P4) JDK-8231427: Warning cleanup in tests of java.io.Serializable
(P5) JDK-8199424: consider removing ObjectInputStream and ObjectOutputStream native methods
core-libs/java.lang:
(P2) JDK-8236695: java.lang.Record should be declared with an explicit constructor
(P3) JDK-8221623: Add StackWalker micro benchmarks to jdk repo
(P3) JDK-8202385: Annotation to mark serial-related fields and methods
(P3) JDK-8231584: Deadlock with ClassLoader.findLibrary and System.loadLibrary call
(P3) JDK-8226242: Diagnostic output for posix_spawn failure
(P3) JDK-8233116: Escape Sequences For Line Continuation and White Space (Preview)
(P3) JDK-8234783: Improve wording of spec of Record.equals
(P3) JDK-8232724: Remove indirection with calling JNU_NewStringPlatform
(P3) JDK-8193325: StackFrameInfo::getByteCodeIndex returns wrong value if bci > 32767
(P3) JDK-8233751: StringBuilder / StringBuffer capacity() doc is misleading
(P4) JDK-8229485: Add decrementExact(), incrementExact(), and negateExact() to java.lang.StrictMath
(P4) JDK-8232135: Add diagnostic output to test java/util/ProcessBuilder/Basic.java
(P4) JDK-8227587: Add internal privileged System.loadLibrary
(P4) JDK-8234381: API docs should mention special handling of enums in serialization
(P4) JDK-8229997: Apply java.io.Serial annotations in java.base
(P4) JDK-8229407: Avoid ConcurrentHashMap resizes during bootstrap
(P4) JDK-8226809: Circular reference in printed stack trace is not correctly indented & ambiguous
(P4) JDK-8227202: clarify Class.isEnum() doc
(P4) JDK-8205132: Degrade Thread.countStackFrames() to throw UOE
(P4) JDK-8231602: Deprecate Thread.suspend/resume for removal
(P4) JDK-8233658: Escape + in the expression describing Runtime.Version string
(P4) JDK-8231717: Improve performance of charset decoding when charset is always compactable
(P4) JDK-8230074: Improve specification for {Math, StrictMath}.negateExact
(P4) JDK-8232624: Java cannot start: NewStringPlatform missing
(P4) JDK-8229337: java.lang.Math class doc should be adjusted regarding -Exact methods
(P4) JDK-8233650: Javadoc for Math.floorMod(int, int) gives wrong example
(P4) JDK-8230104: JNU_IsInstanceOfByName needs const parameter
(P4) JDK-8233940: Preview API tests for String methods should use ${jdk.version} as -source arg
(P4) JDK-8230723: Remove default constructors from java.lang and java.io
(P4) JDK-8226286: Remove unused method java.lang.Integer::formatUnsignedInt and cleanup Integer/Long classes
(P4) JDK-8231355: Remove unused utility methods in libjava
(P4) JDK-8227113: Specification for java.lang.Record
(P4) JDK-8221307: String.substring() OOB exception on start index reports improper information
(P4) JDK-8229283: StringLatin1 should consistently use CharacterDataLatin1.instance when applicable
(P4) JDK-8232617: Update the outdated code comments in java.lang.System class
(P4) JDK-8229831: Upgrade Character.isUnicodeIdentifierStart/Part() methods to the latest standard
(P4) JDK-8230373: Use java.io.Serial in generated exception types
core-libs/java.lang.invoke:
(P1) JDK-8228671: Fastdebug VM throws InternalError when publicLookup.in(T) is used to resolve a member
(P2) JDK-8235351: Lookup::unreflect should bind with the original caller independent of Method's accessible flag
(P3) JDK-8234401: ConstantCallSite may stuck in non-frozen state
(P3) JDK-8232806: Introduce a system property to disable eager lambda initialization
(P3) JDK-8173978: Lookup.in should allow teleporting from a lookup class in a named module without dropping all access
(P3) JDK-8173975: Lookup::in should not allow target class be primitive or array class
(P3) JDK-8233920: MethodHandles::tryFinally generates illegal bytecode for long/double return types
(P3) JDK-8229785: MethodType::fromMethodDescriptorString should require security permission if loader is null
(P4) JDK-8230768: Arrays of SoftReferences in MethodTypeForm should not be @Stable
(P4) JDK-8230302: GenerateJLIClassesPlugin can generate invalid DirectMethodHandle methods
(P4) JDK-8209005: Lookup.unreflectSpecial fails for default methods when Lookup.findSpecial works
(P4) JDK-8233956: MethodHandles.dropArguments javadoc lists parameters in wrong order
(P4) JDK-8230662: Remove dead code from MethodTypeForm
(P4) JDK-8209078: Unable to call default method from interface in another module from named module
(P5) JDK-8236945: typo "the the" in Lookup::in javadoc
core-libs/java.lang.module:
(P2) JDK-8233922: Service binding augments module graph with observable incubator modules
core-libs/java.lang:class_loading:
(P3) JDK-8233091: Backout JDK-8212117: Class.forName loads a class but not linked if class is not initialized
(P3) JDK-8212117: Class.forName may return a reference to a loaded but not linked Class
(P3) JDK-8235361: JAR Class-Path no longer accepts relative URLs encoding absolute Windows paths (e.g "/C:/...")
(P3) JDK-8233272: The Class.forName specification should be updated to match the long-standing implementation with respect to class linking
(P5) JDK-8139820: URLClassPath.FileLoader constructor redundantly checks protocol
core-libs/java.lang:reflect:
(P2) JDK-8235550: Clarify record reflective support specification
(P3) JDK-8207814: (proxy) upgrade the proxy class generator to support new class file version
(P3) JDK-8235369: Class.toGenericString need to be updated for records
(P3) JDK-8225053: Preview APIs support for records
(P4) JDK-8236877: Add "record" to descriptions in java.lang.{annotation, reflect}
(P4) JDK-8234917: Explicitly discuss java.lang.Enum in Class.isEnum spec
(P4) JDK-8219774: Reexamine the initialization of LangReflectAccess shared secret at AccessibleObject::
core-libs/java.math:
(P3) JDK-8233452: java.math.BigDecimal.sqrt() with RoundingMode.FLOOR results in incorrect result
(P4) JDK-8228507: Archive FDBigInteger constants
(P4) JDK-8232195: Enable BigInteger tests: DivisionOverflow, SymmetricRangeTests and StringConstructorOverflow
core-libs/java.net:
(P2) JDK-8232097: (sctp) SctpNet.init() results in java.lang.UnsatisfiedLinkError
(P2) JDK-8236441: Bound MulticastSocket fails when setting outbound interface on Windows
(P2) JDK-8235976: Directives in WWW-Authenticate should be comma separated
(P2) JDK-8068184: Fix for JDK-8032832 caused a deadlock
(P2) JDK-8225425: java.lang.UnsatisfiedLinkError: net.dll: Can't find dependent libraries
(P3) JDK-8230946: Clarify security manager behaviour of a connected DatagramSocket and DatagramChannel
(P3) JDK-8231506: Fix some instabilities in a few networking tests
(P3) JDK-8233185: HttpServer.stop() blocks indefinitely when called on dispatch thread
(P3) JDK-8231632: HttpURLConnection::usingProxy could specify that it may lazily evaluate the fact
(P3) JDK-8225499: InetSocketAddress::toString not friendly to IPv6 literal addresses
(P3) JDK-8230220: java/net/HttpURLConnection/HttpURLProxySelectionTest.java fails intermittently
(P3) JDK-8234823: java/net/Socket/Timeouts.java testcase testTimedConnect2() fails on Windows 10
(P3) JDK-8234629: remove unused functions from libnet
(P3) JDK-8225578: Replace wildcard address with loopback or local host in tests - part 16
(P3) JDK-8226514: Replace wildcard address with loopback or local host in tests - part 17
(P3) JDK-8226825: Replace wildcard address with loopback or local host in tests - part 19
(P3) JDK-8227539: Replace wildcard address with loopback or local host in tests - part 20
(P3) JDK-8229486: Replace wildcard address with loopback or local host in tests - part 21
(P3) JDK-8230435: Replace wildcard address with loopback or local host in tests - part 22
(P3) JDK-8230858: Replace wildcard address with loopback or local host in tests - part 23
(P3) JDK-8185898: setRequestProperty(key, null) results in HTTP header without colon in request
(P3) JDK-8235141: Specify the required standard socket options for the socket types in the java.net package
(P3) JDK-8233886: TEST_BUG jdk/java/net/CookieHandler/B6791927.java hit hardcoded expiration date
(P3) JDK-8232367: Update the jdk/java/net/httpclient tests to RS TCK 1.0.3
(P3) JDK-8214560: Use {@systemProperty} for definitions of system properties (httpserver)
(P4) JDK-8232101: (sctp) Add minimal sanity tests for SCTP
(P4) JDK-8233847: (sctp) Flx link-local IPv6 scope handling and test cleanup.
(P4) JDK-8233845: (sctp) Relax assertion in sun.nio.ch.sctp.AssociationChange::association
(P4) JDK-8233018: Add a new test to verify that DatagramSocket is not interruptible
(P4) JDK-8226319: Add forgotten test/jdk/java/net/httpclient/BodySubscribersTest.java
(P4) JDK-8199849: Add support for UTF-8 encoded credentials in HTTP Basic Authentication
(P4) JDK-8230159: Add test to verify that com.sun.net.httpserver.BasicAuthenticator constructors throw expected exceptions
(P4) JDK-8228970: AssertionError in ResponseSubscribers$HttpResponseInputStream
(P4) JDK-8232853: AuthenticationFilter.Cache::remove may throw ConcurrentModificationException
(P4) JDK-8222968: ByteArrayPublisher is not thread-safe resulting in broken re-use of HttpRequests
(P4) JDK-8228394: Cleanup unused java.net SharedSecrets classes
(P4) JDK-8230438: closed/test/jdk/sun/net/www/protocol/http/ProxyAuthTest.java should not use the wildcard address
(P4) JDK-8235413: com.sun.net.httpserver.BasicAuthenticator.charset is protected field
(P4) JDK-8225479: com.sun.net.httpserver.HttpContext that does not end with '/' has surprising matches
(P4) JDK-8231719: Correct contradictions in timeout range descriptions
(P4) JDK-8234083: DatagramSocket should report SO_BROADCAST as a supported option
(P4) JDK-8233141: DatagramSocket.send doesn't specify exception thrown when no target address
(P4) JDK-8234148: DatagramSocket.setOption/getOption/supportedOption should support multicast options
(P4) JDK-8222829: DatagramSocket.setSoTimeout does not specify IAE when timeout is negative
(P4) JDK-8234103: DatagramSocketImpl::socket is not needed
(P4) JDK-8233319: Deprecate MulticastSocket methods that operate on java.net.InetAddress
(P4) JDK-8226303: Examine the HttpRequest.BodyPublishers for exception handling
(P4) JDK-8225583: Examine the HttpResponse.BodySubscribers for null handling and multiple subscriptions
(P4) JDK-8177648: getResponseCode() throws IllegalArgumentException caused by protocol error while following redirect
(P4) JDK-8232625: HttpClient redirect policy should be more conservative
(P4) JDK-8231449: HttpClient's client ssl certificate authentication seems to be broken.
(P4) JDK-8223714: HTTPSetAuthenticatorTest could be made more resilient
(P4) JDK-8227720: Improve ExtendedSocketOptions initialization
(P4) JDK-8217705: java.net.http.HttpClient: wrong exception type when bad status line is received
(P4) JDK-8191169: java/net/Authenticator/B4769350.java failed intermittently
(P4) JDK-8193596: java/net/DatagramPacket/ReuseBuf.java failed due to timeout
(P4) JDK-8232513: java/net/DatagramSocket/PortUnreachable.java still fails intermittently with BindException
(P4) JDK-8229348: java/net/DatagramSocket/UnreferencedDatagramSockets.java fails intermittently
(P4) JDK-8231038: java/net/httpclient/ShortRequestBody.java failed intermittently
(P4) JDK-8231037: java/net/InetAddress/ptr/Lookup.java fails intermittently due to reverse lookup failed
(P4) JDK-8230132: java/net/NetworkInterface/NetworkInterfaceRetrievalTests.java to skip Teredo Tunneling Pseudo-Interface
(P4) JDK-8233860: java/net/SocketOption/AfterClose.java test incorrectly handles IP_MULTICAST_IF
(P4) JDK-8171405: java/net/URLConnection/ResendPostBody.java failed with "Error while cleaning up threads after test"
(P4) JDK-8230856: Java_java_net_NetworkInterface_getByName0 on unix misses ReleaseStringUTFChars in early return
(P4) JDK-8230526: jdk.internal.net.http.PlainProxyConnection is never reused by HttpClient
(P4) JDK-8233958: Memory retention due to HttpsURLConnection finalizer that serves no purpose
(P4) JDK-8233307: MulticastSocket getOption(IP_MULTICAST_IF) returns interface when not set
(P4) JDK-8233296: MulticastSocket getOption/setOption inverts the value of IP_MULTICAST_LOOP
(P4) JDK-8233191: MulticastSocket joinGroup/leaveGroup do not specify their behavior when the outgoing interface has not been set
(P4) JDK-8231516: network QuickAckTest.java failed due to "SocketException: maximum number of DatagramSockets reached"
(P4) JDK-8209178: Proxied HttpsURLConnection doesn't send BODY when retrying POST request
(P4) JDK-8225239: Refactor NetworkInterface lookups
(P4) JDK-8234501: remove obsolete NET_ReadV
(P4) JDK-8225430: Replace wildcard address with loopback or local host in tests - part 14
(P4) JDK-8226756: Replace wildcard address with loopback or local host in tests - part 18
(P4) JDK-8230310: SocksSocketImpl should handle the IllegalArgumentException thrown by ProxySelector.select usage
(P4) JDK-8229481: sun/net/www/protocol/https/ChunkedOutputStream.java failed with a SSLException
(P4) JDK-8226602: Test convenience reactive primitives from java.net.http with RS TCK
(P4) JDK-8227721: test/jdk/java/net/NetworkInterface/NetworkInterfaceRetrievalTests.java should open the java.net package
(P4) JDK-8229421: The logic of java/net/ipv6tests/TcpTest.java is flawed
(P4) JDK-8231504: Update networking tests to avoid implicit dependency on the system proxies
(P4) JDK-8222363: Update ServerSocket.isBound spec to reflect implementation after close
(P4) JDK-8078219: Verify lack of @test tag in files in java/net test directory
(P5) JDK-8203036: com.sun.net.httpserver.HttpExchange should implement AutoCloseable
(P5) JDK-8229916: Delete redundant test java/net/Socket/reset/Test.java
(P5) JDK-8230694: http.keepAlive system property is inconsistently/incorrectly documented
(P5) JDK-8177389: Hyphen "-" should be removed in URL class documentation
core-libs/java.nio:
(P2) JDK-8236582: (fc) FileChannel.map fails with InternalError when security manager enabled
(P2) JDK-8230085: (fs) FileStore::isReadOnly is always true on macOS Catalina
(P2) JDK-8232879: (zipfs) Writing out data with ZipFileSystem leads to a CRC failure in the generated jar file
(P2) JDK-8229887: (zipfs) zip file corruption when replacing an existing STORED entry
(P3) JDK-8230665: (bf spec) ByteBuffer::alignmentOffset spec misleading when address is misaligned
(P3) JDK-8184157: (ch) AsynchronousFileChannel hangs with internal error when reading locked file
(P3) JDK-8234805: (dc) Remove JNI upcall from DatagramChannel.receive implementation
(P3) JDK-8227080: (fs) Files.newInputStream(...).skip(n) is slow
(P3) JDK-8227609: (fs) Files.newInputStream(...).skip(n) should allow skipping beyond file size
(P3) JDK-8162520: (fs) FileStore should support file stores with > Long.MAX_VALUE capacity
(P3) JDK-8216472: (se) Stack overflow during selection operation leads to crash (win)
(P3) JDK-8213031: (zipfs) Add support for POSIX file permissions
(P3) JDK-8223771: (zipfs) FileSystemProvider.newFileSystem(Path, Map) should throw IOException when called with a file that cannot be open
(P3) JDK-8237183: Bug ID missing for test in patch which fixed JDK-8230665
(P3) JDK-8236804: java/nio/channels/FileChannel/MapWithSecurityManager.java should be run in othervm mode
(P3) JDK-8234824: java/nio/channels/SocketChannel/AdaptSocket.java fails on Windows 10
(P3) JDK-8236661: Launcher test PatchSystemModules.java fails frequently after JDK-8234049
(P3) JDK-8237514: Spec Clarification - ByteBuffer::alignmentOffset Spec
(P4) JDK-8164993: (ch) ReadableByteChannel should note a possible IllegalArgumentException
(P4) JDK-8146298: (dc spec) connect and disconnect methods should specify that they may block
(P4) JDK-8231570: (dc) Clarify implicit bind behavior of DatagramChannel
(P4) JDK-8233435: (dc) DatagramChannel should allow IPv6 socket join IPv4 multicast groups (macOS, win)
(P4) JDK-8232673: (dc) DatagramChannel socket adaptor issues
(P4) JDK-8231260: (dc) DatagramChannel::disconnect changes the port of the local address to 0 (lnx)
(P4) JDK-8231259: (dc) DatagramChannel::disconnect re-binds socket to the wildcard address (macOS)
(P4) JDK-8212132: (dc) Remove DatagramChannelImpl finalize method
(P4) JDK-8235193: (dc) Remove JNI overhead from DatagramChannel.send implementation
(P4) JDK-8181493: (fs) Files.readAttributes(path, BasicFileAttributes.class) should preserve nano second time stamps
(P4) JDK-8232003: (fs) Files.write can leak file descriptor in the exception case
(P4) JDK-8231174: (fs) FileTime should have 100ns resolution (win)
(P4) JDK-8229872: (fs) Increase buffer size used with getmntent
(P4) JDK-8231149: (fs) Small verbiage errors in java.nio.file package documentation
(P4) JDK-8233430: (sc) Socket adaptor restoring of blocking mode can override exception if socket closed
(P4) JDK-8226706: (se) Reduce the number of outer loop iterations on Windows in java/nio/channels/Selector/RacyDeregister.java
(P4) JDK-8231603: (se) Selector implementations do not need to use cancelledKeys
(P4) JDK-8231921: (se) SelectorImpl.register does not need to set the attachment when it is null
(P4) JDK-8231766: (zipfs) Files.copy/move should honor the compression method specified
(P4) JDK-8230870: (zipfs) Add a ZIP FS test that is similar to test/jdk/java/util/zip/EntryCount64k.java
(P4) JDK-8234080: (zipfs) jdk/nio/zipfs/CRCWriteTest.java fails
(P4) JDK-8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater()
(P4) JDK-8233622: (zipfs) open/test/jdk/jdk/nio/zipfs/CopyMoveTests.java has incorrect bug label
(P4) JDK-8234089: (zipfs) Remove classes JarFileSystemProvider and JarFileSystem
(P4) JDK-8235475: Add additional timestamp to test java/nio/channels/Selector/SelectWithConsumer.java
(P4) JDK-8232045: cleanup AIX 5.3 workarounds from libnio/ch/Net.c
(P4) JDK-8231450: Copyright header line omitted from 8231187 changeset
(P4) JDK-8231093: Document the ZIP FS properties noCompression and releaseVersion
(P4) JDK-8207851: JEP 352: Non-Volatile Mapped Byte Buffers
(P4) JDK-8231187: SelectorProvider.inheritedChannel() returns TCP socket channel for Unix domain socket
(P5) JDK-8223813: (aio) Iocp.getErrorMessage should drop trailing \r\n
core-libs/java.nio.charsets:
(P2) JDK-8229960: Remove sun.nio.cs.map system property
(P4) JDK-8230531: API Doc for CharsetEncoder.maxBytesPerChar() should be clearer about BOMs
core-libs/java.rmi:
(P2) JDK-8237368: Problem with NullPointerException in RMI TCPEndpoint.read
(P4) JDK-8232446: logging enhancement for rmi when socket closed
(P4) JDK-8230058: Replace exception from sun.rmi.runtime.Log#getSource() with StackWalker
core-libs/java.sql:
(P3) JDK-8226518: Example in java.sql.ConnectionBuilder spec doesn't comply to its actual API
(P3) JDK-8225680: Questionable links to java.sun.com
(P4) JDK-8226808: Documentation error in code sample of PreparedStatement
(P4) JDK-8184432: reference to jdbc@sun.com
core-libs/java.text:
(P4) JDK-8215181: Accounting currency format support
(P4) JDK-8230284: Accounting currency format support does not cope with explicit number system
(P4) JDK-8231984: Clarify semantics of DecimalFormat.getGroupingSize(0)
(P4) JDK-8212749: DecimalFormat.setGroupingSize(int) allows setting negative grouping size
(P4) JDK-8232860: Error formatting integer values with MessageFormat.format() using HOST provider
(P4) JDK-8231213: Migrate SimpleDateFormatConstTest to JDK Repo
(P4) JDK-8236495: open/test/jdk/java/util/Locale/LocaleProvidersRun.java failed on mac 10.14 with de_DE locale.
core-libs/java.time:
(P2) JDK-8212970: TZ database in "vanguard" format support
(P3) JDK-8224560: (tz) Upgrade time-zone data to tzdata2019a
(P3) JDK-8231098: (tz) Upgrade time-zone data to tzdata2019c
(P3) JDK-8225580: tzdata2018i integration causes test failures on jdk-13
(P4) JDK-8228469: (tz) Upgrade time-zone data to tzdata2019b
(P4) JDK-8211990: DateTimeException thrown when calculating duration between certain dates
(P4) JDK-8230136: DateTimeFormatterBuilder.FractionPrinterParser#parse fails to verify minWidth
(P4) JDK-8231314: java.time serialization warning cleanup
(P4) JDK-8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string
(P4) JDK-8233799: Review the need for overview.html in the java.time package
(P4) JDK-8220229: Timezone pattern "OOOO" does not result in the full "GMT+00:00" substring
core-libs/java.util:
(P3) JDK-8223490: Optimize search algorithm for determining default time zone
(P4) JDK-8226297: Dual-pivot quicksort improvements
(P4) JDK-8224716: Javadoc of Int/Long/DoubleSummaryStatistics should mention possible overflow of count
(P4) JDK-8234799: javadoc of java.util.Arrays.compare(T[] a, T[] b) misses the word "less"
(P4) JDK-8231124: Missing closedir call with JDK-8223490
(P4) JDK-8231777: Remove extraneous @serial javadoc tag in NodeChangeEvent.java
(P4) JDK-8233731: repeated typo "fro" for "for"
(P4) JDK-8231546: Suppress warnings on non-serializable instance fields in java.prefs module
(P4) JDK-8231202: Suppress warnings on non-serializable non-transient instance fields in serializable classes
core-libs/java.util.concurrent:
(P2) JDK-8229442: AQS and lock classes refresh
(P3) JDK-8231592: Clarify that ConcurrentHashMap compute methods mapping functions execute at most once
(P3) JDK-8225490: Miscellaneous changes imported from jsr166 CVS 2019-09
(P3) JDK-8231026: Miscellaneous changes imported from jsr166 CVS 2019-11
(P3) JDK-8231032: ThreadMXBean locking tests fail after JSR 166 refresh
(P4) JDK-8145138: CyclicBarrier/Basic.java failed with "3 not equal to 4"
(P4) JDK-8227235: rare failures in testForkHelpQuiesce tck tests
(P4) JDK-8232230: Suppress warnings on non-serializable non-transient instance fields in java.util.concurrent
core-libs/java.util.jar:
(P3) JDK-8226530: ZipFile reads wrong entry size from ZIP64 entries
(P3) JDK-8213561: ZipFile/MultiThreadedReadTest.java timed out in tier1
(P4) JDK-8231770: Test java/util/zip/FlaterTest.java fails with -Xcheck:jni
(P4) JDK-8233721: Update JAR spec regarding when the last character is an EOF in a Manfiest
(P4) JDK-8231451: ZipFileInputStream.skip does not handle negative values correctly
(P4) JDK-8234079: ZipFileInputStreamSkipTest.java runs zero test
core-libs/java.util.regex:
(P4) JDK-8230338: Accurate error message about bad Unicode block name
(P4) JDK-8228352: CANON_EQ breaks when pattern contains supplementary codepoint
(P4) JDK-8224849: Flag (?U:...) is allowed for non-capturing groups
(P4) JDK-8230829: Matcher matches a surrogate pair that crosses border of the region
core-libs/java.util.stream:
(P4) JDK-8235730: Incorrect javadoc in MatchKind
(P4) JDK-8231161: Wrong return type in code sample in Collector API documentation
core-libs/java.util:collections:
(P3) JDK-8234423: Modifying ArrayList.subList().subList() resets modCount of subList
(P4) JDK-8231913: Discuss serializability of collections
(P4) JDK-8225339: Optimize HashMap.keySet()/HashMap.values()/HashSet toArray() methods
(P5) JDK-8229338: clean up test/jdk/java/util/RandomAccess/Basic.java
core-libs/java.util:i18n:
(P1) JDK-8238605: Correct the CLDR version number in cldr.md files
(P3) JDK-8228465: HOST locale provider holds wrong era name for GregorianCalendar in US locale
(P3) JDK-8222756: Plural support in CompactNumberFormat
(P3) JDK-8231273: Upgrade CLDR to v36
(P3) JDK-8225435: Upgrade IANA Language Subtag Registry to the latest for JDK14
(P4) JDK-8233579: DateFormatSymbols.getShortMonths() return wrong string on es_CL, es_CO locales
(P4) JDK-8227289: Enable assertions for some shell to java conversion tests after JDK-8218960
(P4) JDK-8232871: Host Locale Provider on Mac does not return translated values of Japanese calendar
(P4) JDK-8234288: Turkey Time Zone returns incorrect time zone name
core-libs/javax.lang.model:
(P3) JDK-8222369: ExecutableElement.getReceiverType returns null instead of NOTYPE
(P3) JDK-8237062: Refine JSR 269 API ahead of Java SE 14 MR
(P4) JDK-8214547: Add SourceVersion.RELEASE_14
(P4) JDK-8230337: Clarify intention of Elements.{getPackageOf, getModuleOf}
(P4) JDK-8224630: ElementScannerN, N > 9 should scan type parameters
(P4) JDK-8235541: Extend javax.lang.model to cover binding variables
(P4) JDK-8225052: javax.lang.model support for records
(P4) JDK-8230626: Make UnknownFooException strings more informative
(P4) JDK-8233096: Update javax.lang.model for switch expressions
(P4) JDK-8230882: Use @index in javax.lang.model javadoc
core-libs/javax.naming:
(P2) JDK-8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect
(P2) JDK-8217606: LdapContext#reconnect always opens a new connection
(P4) JDK-8141685: com/sun/jndi/ldap/InvalidLdapFilters.java initializes context failed
(P4) JDK-8223727: com/sun/jndi/ldap/privconn/RunTest.java failed due to hang in LdapRequest.getReplyBer
(P4) JDK-8228580: DnsClient TCP socket timeout
(P4) JDK-8232076: Suppress warnings on non-serializable non-transient instance fields in java.naming
core-libs/javax.sql:
(P2) JDK-8235961: Default javax.sql.rowset.spi.SyncResolver impl returned by SyncProviderException throws unspecified NPE, UOE
(P4) JDK-8231442: Suppress warnings on non-serializable instance fields in java.sql.* modules
core-libs/jdk.nashorn:
(P3) JDK-8230709: Array index out of bounds in ES6 mode
(P3) JDK-8222205: java.lang.NullPointerException when using jjs with r.js
(P3) JDK-8228702: Nashorn reports NaN for undefined
(P4) JDK-8223451: Make optimistic types disabled by default
(P4) JDK-8231557: Suppress warnings on non-serializable instance fields in jdk.scripting.nashorn module
(P4) JDK-8232209: Update double-conversion license file to version 3.1.5
(P4) JDK-8232984: Upgrading Joni License version to 2.1.16
(P5) JDK-8230766: Changed message in IllegalMonitorStateException
core-svc:
(P4) JDK-8230901: missing ReleaseStringUTFChars in serviceability native code
core-svc/debugger:
(P3) JDK-8170299: Debugger does not stop inside the low memory notifications code
(P3) JDK-8227693: HTML error in jdwp-protocol.html
(P3) JDK-8230516: invalid html in jdwp-protocol.html
(P3) JDK-8230303: JDB hangs when running monitor command
(P3) JDK-8182119: jdk.hotspot.agent's META-INF/services/com.sun.jdi.connect.Connector no longer needed
(P4) JDK-8231600: Avoid GCC 8 strncpy error in jdk.jdwp.agent
(P4) JDK-8192057: com/sun/jdi/BadHandshakeTest.java fails with java.net.ConnectException
(P4) JDK-8227231: JDWP help information shows use of obsolete Xdebug flag
(P4) JDK-8224159: JDWP IPv6 scope support
(P4) JDK-8229378: jdwp library loader in linker_md.c quietly truncates on buffer overflow
(P4) JDK-8232182: RedefineNestmateAttr/TestNestmateAttr.java fails due to ObjectCollectedException
(P4) JDK-8232370: Refactor some com.sun.jdi tests to enable IDE integration
(P4) JDK-8186825: some memory leak issues in the transport_startTransport
(P4) JDK-8232448: Suppress warnings on non-serializable non-transient instance fields in jdk.jdi
(P4) JDK-8231915: two JDI tests interfere with each other
(P4) JDK-8235360: Update JDWP, JDI and Instrumentation specs for Record attribute
core-svc/java.lang.management:
(P2) JDK-8231666: ThreadIdTable::grow() invokes invalid thread transition
(P3) JDK-8226575: OperatingSystemMXBean should be made container aware
(P4) JDK-8231210: [BACKOUT] JDK-8207266 ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread
(P4) JDK-8231209: [REDO] JDK-8207266 ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread
(P4) JDK-8231968: getCurrentThreadAllocatedBytes default implementation s/b getThreadAllocatedBytes
(P4) JDK-8185005: Improve performance of ThreadMXBean.getThreadInfo(long ids[], int maxDepth)
(P4) JDK-8207266: ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread
core-svc/javax.management:
(P4) JDK-8206179: com/sun/management/OperatingSystemMXBean/GetCommittedVirtualMemorySize.java fails with Committed virtual memory size illegal value
(P4) JDK-8232442: Suppress warnings on non-serializable non-transient instance fields in java.management.*
core-svc/tools:
(P3) JDK-8228589: BasicJStackTest.java and JcmdOutputEncodingTest.java failing after JDK-8227868
(P3) JDK-8225543: Jcmd fails to attach to the Java process on Linux using the main class name if whitespace options were used to launch the process
(P3) JDK-8225715: jhsdb jmap fails to write binary heap dump of a jshell process
(P3) JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java fails: Bad file descriptor
(P4) JDK-8229847: AttachProvider javadoc page needs an update
(P4) JDK-8227440: Implement fix to JDK-8224642 on all platforms
(P4) JDK-8227868: jinfo and jstack can fail converting UTF8 output to strings
(P4) JDK-8227435: Perf::attach() should not throw a java.lang.Exception
(P4) JDK-8233868: Unproblem list sun/tools/jstat/jstatClassloadOutput1.sh
(P5) JDK-8199136: Dead code in src/jdk.jcmd/share/classes/sun/tools/common/ProcessArgumentMatcher.java
(P5) JDK-8233790: Forward output from heap dumper to jcmd/jmap
deploy:
(P3) JDK-8222563: Remove terminally deprecated method netscape.javascript.JSObject::getWindow
docs:
(P3) JDK-8232972: document how $APPDIR can be used in --java-options
(P3) JDK-8227641: document how java-options values with spaces are processed
(P5) JDK-8233422: Extra space in the title of the HTML javadoc page
docs/guides:
(P3) JDK-8184207: Add the supported SSL/TLS protocol versions for each SSLContext algorithm in the "JDK Providers" documentation
(P3) JDK-8236624: Document the jdk.tls.client.enableSessionTicketExtension, jdk.tls.server.enableSessionTicketExtension and jdk.tls.server.sessionTicketTimeout system properties
(P4) JDK-8234598: Update SunJSSE section of JDK Providers guide to use keytool to list enabled cipher suites
docs/tools:
(P2) JDK-8237058: Update all nroff manpages for JDK 14 release
globalization/translation:
(P2) JDK-8237465: JDK 14 L10n resource file update - msg drop 10
(P2) JDK-8238377: JDK 14 L10n resource file update - msg drop 20
hotspot:
(P2) JDK-8226515: AArch64: float point register corruption in ZBarrierSetAssembler::load_at
(P3) JDK-8233328: fix minimal VM build on Linux s390x
(P4) JDK-8233741: AES Countermode (CTR) optimization using AVX512 + VAES instructions
(P4) JDK-8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power
(P4) JDK-8231448: s390 and ppc - replace JVM type comparisons to T_OBJECT and T_ARRAY with call to is_reference_type
(P5) JDK-8224851: AArch64: fix warnings and errors with Clang and GCC 8.3
hotspot/compiler:
(P1) JDK-8233918: 8233498 broke build on SPARC
(P1) JDK-8230020: [BACKOUT] compiler/types/correctness/* tests fail with "assert(recv == __null || recv->is_klass()) failed: wrong type"
(P1) JDK-8234891: AArch64: Fix build failure after JDK-8234387
(P1) JDK-8230671: x86_32 build failures after JDK-8229496
(P2) JDK-8230061: # assert(mode == ControlAroundStripMined && use == sfpt) failed: missed a node
(P2) JDK-8231515: [Graal] Crash during exception throwing in InterpreterRuntime::resolve_invoke
(P2) JDK-8227068: [Graal] MappedByteBuffer bulk access memory failures are not handled gracefully
(P2) JDK-8232106: [x86] C2: SIGILL due to usage of SSSE3 instructions on processors which don't support it
(P2) JDK-8229701: aarch64: C2 OSR compilation fails with "shouldn't process one node several times" in final graph reshaping
(P2) JDK-8234432: AOT tests failing with 'used 'epsilon gc' is different from current 'g1 gc'' after CMS removal
(P2) JDK-8234645: ARM32: C1: PatchingStub for field access: not enough bytes
(P2) JDK-8231620: assert(bol->is_Bool()) crash during split if due to FastLockNode
(P2) JDK-8230062: assert(i == p->size()-1) failed: must be last element of the pack
(P2) JDK-8233032: assert(in_bb(n)) failed: must be
(P2) JDK-8230185: assert(is_Loop()) failed: invalid node class
(P2) JDK-8234350: assert(mode == ControlAroundStripMined && (use == sfpt || !use->is_reachable_from_root())) failed: missed a node
(P2) JDK-8229450: C2 compilation fails with assert(found_sfpt) failed: no node in loop that's not input to safepoint
(P2) JDK-8224957: C2 compilation fails with assert: Bad graph detected in build_loop_late
(P2) JDK-8235870: C2 crashes in IdealLoopTree::est_loop_flow_merge_sz()
(P2) JDK-8233033: C2 produces wrong result while unswitching a loop due to lost control dependencies
(P2) JDK-8229016: C2 scalarization crashes with assert(node->Opcode() == Op_CastP2X) failed: ConvP2XNode required
(P2) JDK-8231055: C2: arraycopy with same non escaping src and dest but different positions causes wrong execution
(P2) JDK-8235984: C2: assert(out->in(PhiNode::Region) == head || out->in(PhiNode::Region) == slow_head) failed: phi must be either part of the slow or the fast loop
(P2) JDK-8231550: C2: ShouldNotReachHere() in verify_strip_mined_scheduling
(P2) JDK-8233590: Compiler thread creation fails with assert(_c2_count > 0 || _c1_count > 0) failed: No compilers?
(P2) JDK-8232883: compiler/c2/CmpPNodeSubTest.java fails because test class name is wrong
(P2) JDK-8235636: gc/shenandoah/compiler/TestUnsafeOffheapSwap.java fails after JDK-8226411
(P2) JDK-8232882: GCC 4.8.5 build failure after JDK-8211073
(P2) JDK-8226871: invalid use of incomplete type class MacroAssembler when building minimal after JDK-8191278
(P2) JDK-8229694: JVM crash in SWPointer during C2 OSR compilation
(P2) JDK-8233529: loopTransform.cpp:2984: Error: assert(p_f->Opcode() == Op_IfFalse) failed
(P2) JDK-8191278: MappedByteBuffer bulk access memory failures are not handled gracefully
(P2) JDK-8234610: MaxVectorSize set wrongly when UseAVX=3 is specified after JDK-8221092
(P2) JDK-8234923: Missed call_site_target nmethod dependency for non-fully initialized ConstantCallSite instance
(P2) JDK-8228839: Non-CFG nodes have control edges to calls, instead of the call's control projection
(P2) JDK-8233027: OopMapSet::all_do does oms.next() twice during iteration
(P2) JDK-8229496: SIGFPE (division by zero) in C2 OSR compiled method
(P2) JDK-8232539: SIGSEGV in C2 Node::unique_ctrl_out
(P2) JDK-8235452: Strip mined loop verification fails with assert(is_OuterStripMinedLoop()) failed: invalid node class
(P2) JDK-8236364: TEMP vector registers could be incorrectly assigned upper bank xmm registers after Generic Operands (JDK-8234391)
(P2) JDK-8231988: Unexpected test result caused by C2 IdealLoopTree::do_remove_empty_loop
(P2) JDK-8231713: x86_32 build failures after JDK-8226721 (Missing intrinsics for Math.ceil, floor, rint)
(P2) JDK-8226878: zero crashes after JDK-8191278
(P2) JDK-8229970: ZGC: C2: fixup_uses_in_catch may fail when expanding many uses
(P3) JDK-8235998: [C2] Memory leaks during tracing after "8224193: stringStream should not use Resource Area".
(P3) JDK-8230059: [Graal] Initialized array might be set to null if initialized with negative size
(P3) JDK-8235539: [JVMCI] -XX:+EnableJVMCIProduct breaks -XX:-EnableJVMCI
(P3) JDK-8229377: [JVMCI] Improve InstalledCode.invalidate for large code caches
(P3) JDK-8234359: [JVMCI] invalidate_nmethod_mirror shouldn't use a phantom reference
(P3) JDK-8231754: [JVMCI] Make r27 unconditionally reserved in JVMCI
(P3) JDK-8235438: [JVMCI] StackTraceElement::decode should use the original Method
(P3) JDK-8230019: [REDO] compiler/types/correctness/* tests fail with "assert(recv == __null || recv->is_klass()) failed: wrong type"
(P3) JDK-8230669: [s390] C1: assert(is_bound() || is_unused()) failed: Label was never bound to a location, but it was used as a jmp target
(P3) JDK-8232828: AArch64: compiler/c2/aarch64/TestVolatilesG1.java fails with "Missing expected output membar_volatile..."
(P3) JDK-8226953: AOT: assert(oopDesc::is_oop(obj)) failed: not an oop
(P3) JDK-8234893: ARM32: build failure after JDK-8234387
(P3) JDK-8229961: Assert failure in compiler/graalunit/HotspotTest.java
(P3) JDK-8236140: assert(!VerifyHashTableKeys || _hash_lock == 0) failed: remove node from hash table before modifying it
(P3) JDK-8234616: assert(0 <= i && i < _len) failed: illegal index in PhaseMacroExpand::expand_macro_nodes()
(P3) JDK-8233656: assert(d->is_CFG() && n->is_CFG()) failed: must have CFG nodes
(P3) JDK-8229994: assert(false) failed: Bad graph detected in get_early_ctrl_for_expensive
(P3) JDK-8235288: AVX 512 instructions inadvertently used on Xeon for small vector width operations
(P3) JDK-8236179: C1 register allocation failure with T_ADDRESS
(P3) JDK-8234617: C1: Incorrect result of field load due to missing narrowing conversion
(P3) JDK-8228772: C2 compilation fails due to unschedulable graph if DominatorSearchLimit is reached
(P3) JDK-8227384: C2 compilation fails with "graph should be schedulable" when running with -XX:-EliminateLocks
(P3) JDK-8228888: C2 compilation fails with assert "m has strange control"
(P3) JDK-8229855: C2 fails with assert(false) failed: bad AD file
(P3) JDK-8233164: C2 fails with assert(phase->C->get_alias_index(t) == phase->C->get_alias_index(t_adr)) failed: correct memory chain
(P3) JDK-8231223: C2's conditional move optimization fails with assert(bol->Opcode() == Op_Bool) failed
(P3) JDK-8226411: C2: Avoid memory barriers around off-heap unsafe accesses
(P3) JDK-8234387: C2: Better support of operands with multiple match rules in AD files
(P3) JDK-8234394: C2: Dynamic register class support in ADLC
(P3) JDK-8234392: C2: Extend Matcher::match_rule_supported_vector() with element type information
(P3) JDK-8234391: C2: Generic vector operands
(P3) JDK-8230363: C2: Let ConnectionGraph::not_global_escape(Node* n) return false if n is not in the CG
(P3) JDK-8231430: C2: Memory stomp in max_array_length() for T_ILLEGAL type
(P3) JDK-8235688: C2: Merge AD instructions for AddV, SubV, and MulV nodes
(P3) JDK-8235405: C2: Merge AD instructions for different vector operations
(P3) JDK-8235756: C2: Merge AD instructions for DivV, SqrtV, and FmaV nodes
(P3) JDK-8235719: C2: Merge AD instructions for ShiftV, AbsV, and NegV nodes
(P3) JDK-8235143: C2: No memory state needed in Thread::currentThread() intrinsic
(P3) JDK-8236181: C2: Remove useless step_over_gc_barrier() in int->bool conversion
(P3) JDK-8231321: compiler/codecache/stress/UnexpectedDeoptimizationAllTest.java failed assertion
(P3) JDK-8225670: compiler/types/correctness/* tests fail with "assert(recv == __null || recv->is_klass()) failed: wrong type"
(P3) JDK-8230711: ConnectionGraph::unique_java_object(Node* N) return NULL if n is not in the CG
(P3) JDK-8226409: Enable argument profiling for sun.misc.Unsafe.put*/get*
(P3) JDK-8236772: Fix build for windows 32-bit after 8212160 and 8234331.
(P3) JDK-8234863: Increase default value of MaxInlineLevel
(P3) JDK-8236443: Issues with specializing vector register type for phi operand with generic operands
(P3) JDK-8233019: java.lang.Class.isPrimitive() (C1) returns wrong result if Klass* is aligned to 32bit
(P3) JDK-8235510: java.util.zip.CRC32 performance drop after 8200067
(P3) JDK-8235762: JVM crash in SWPointer during C2 compilation
(P3) JDK-8231565: More node budget asserts in fuzzed tests
(P3) JDK-8165056: move JIT Compiler related files from runtime/ to compiler/ directory
(P3) JDK-8229499: Node budget assert in fuzzed test
(P3) JDK-8234583: PrintAssemblyOptions isn't passed to hsdis library
(P3) JDK-8225653: Provide more information when hitting SIGILL from HaltNode
(P3) JDK-8234681: Remove UseJVMCIClassLoader logic from JVMCI code
(P3) JDK-8233788: Remove useless asserts in PhaseCFG::insert_anti_dependences
(P3) JDK-8230470: Shenandoah doesn't need change from JDK-8212610 anymore
(P3) JDK-8231499: Shenandoah: compiler/arraycopy/TestDefaultMethodArrayCloneDeoptC2 fails
(P3) JDK-8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken
(P3) JDK-8229483: Sinking load out of loop may trigger: assert(found_sfpt) failed: no node in loop that's not input to safepoint
(P3) JDK-8236050: Some compiler tests fail when executed with custom TieredLevel
(P3) JDK-8231720: Some perf regressions after 8225653
(P3) JDK-8236944: The legVecZ operand should be limited to zmm0-zmm15 registers
(P3) JDK-8227439: Turn off AOT by default
(P3) JDK-8235927: Update Graal
(P3) JDK-8221092: UseAVX=3 has performance degredation on Skylake (X7) processors
(P3) JDK-8235584: UseProfiledLoopPredicate fails with assert(_phase->get_loop(c) == loop) failed: have to be in the same loop
(P3) JDK-8236000: VM build without C2 fails
(P3) JDK-8231501: VM crash in MethodData::clean_extra_data(CleanExtraDataClosure*): fatal error: unexpected tag 99
(P3) JDK-8234520: ZGC: C2: Oop instance cloning causing skipped compiles
(P3) JDK-8233506: ZGC: the load for Reference.get() can be converted to a load for strong refs
(P4) JDK-8231665: 8231055 broke escapeAnalysis/TestSelfArrayCopy.java
(P4) JDK-8230434: [C1, C2] Release barrier for volatile field stores in constructors implemented inconsistently
(P4) JDK-8213264: [Graal] 95% regression to C2 on AESGCMBench.decrypt AES/GCM/NoPadding
(P4) JDK-8234499: [Graal] compiler/compilercontrol/CompilationModeHighOnlyTest.java test fails with timeout
(P4) JDK-8231903: [Graal] Update com.oracle.mxtool.junit classes
(P4) JDK-8229797: [JVMCI] Clean up no longer used JVMCI::dependencies_invalid value
(P4) JDK-8231659: [JVMCI] Could not work PrintAssembly for JVMCI installed code
(P4) JDK-8226222: [JVMCI] Export AArch64 field VM_Version::_psr_info.dczid_el0
(P4) JDK-8233900: [JVMCI] improve help text for EnableJVMCIProduct option
(P4) JDK-8233745: [JVMCI] TranslatedException should serialize classloader and module info
(P4) JDK-8231757: [ppc] Fix VerifyOops. Errors show since 8231058.
(P4) JDK-8231403: [ppc]: Align ReservedCodeCacheSize default value with other platforms
(P4) JDK-8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl
(P4) JDK-8233948: AArch64: Incorrect mapping between OptoReg and VMReg for high 64 bits of Vector Register
(P4) JDK-8223968: Add abort type description to RTM statistic counters
(P4) JDK-8227003: Add high-level JIT compilation mode control mechanism
(P4) JDK-8233389: Add PrintIdeal to compiler directives
(P4) JDK-8234331: Add robust and optimized utility for rounding up to next power of two
(P4) JDK-8230091: Add verification of clean_catch_blocks
(P4) JDK-8225625: AES Electronic Codebook (ECB) encryption and decryption optimization using AVX512 + VAES instructions
(P4) JDK-8231955: ARM32: Address displacement is 0 for volatile field access because of Unsafe field access.
(P4) JDK-8231952: ARM32: Wrong assumption in assertion in LIRGenerator::atomic_xchg and LIRGenerator::atomic_add
(P4) JDK-8223769: Assert triggers with -XX:+StressReflectiveCode
(P4) JDK-8227236: assert(singleton != __null && singleton != declared_interface) failed
(P4) JDK-8235383: C1 compilation fails with -XX:+PrintIRDuringConstruction -XX:+Verbose
(P4) JDK-8234541: C1 emits an empty message when it inlines successfully
(P4) JDK-8233081: C1: PatchingStub for field access copies too much
(P4) JDK-8231085: C2/GC: Better GC-interface for expanding clone
(P4) JDK-8234403: C2: Enable CallSite.target updates in constructors
(P4) JDK-8231412: C2: InitializeNode::detect_init_independence() bails out on simple IR shapes
(P4) JDK-8220376: C2: Int >0 not recognized as !=0 for div by 0 check
(P4) JDK-8234321: Call cache flush after generating trampoline.
(P4) JDK-8230762: Change MacroAssembler::debug32/64 to use fatal instead of assert
(P4) JDK-8235653: Clean-up BarrierSetC2
(P4) JDK-8230428: Cleanup dead CastIP node code in formssel.cpp
(P4) JDK-8220416: Comparison of klass pointers is not optimized any more
(P4) JDK-8226795: compiler/tiered/Level2RecompilationTest.java fails when XX:TieredStopAtLevel=1/2/3 is set
(P4) JDK-8230037: Confused MetaData dumped by PrintOptoAssembly
(P4) JDK-8233491: Crash in AdapterHandlerLibrary::get_adapter with CDS due to code cache exhaustion
(P4) JDK-8231626: DeoptimizeRandom should not be a product flag
(P4) JDK-8222079: Don't use memset to initialize fields decode_env constructor in disassembler.cpp
(P4) JDK-8231586: enlarge encoding space for OopMapValue offsets
(P4) JDK-8230943: False deadlock detection with -XX:+CIPrintCompileQueue after JDK-8163511
(P4) JDK-8233364: Fix undefined behavior in Canonicalizer::do_ShiftOp
(P4) JDK-8233941: Generated Pipeline_Use_Cycle_Mask::operator= interferes with memcpy updates
(P4) JDK-8233273: Graal Update
(P4) JDK-8234003: Improve IndexSet iteration
(P4) JDK-8224624: Inefficiencies in CodeStrings::add_comment cause timeouts
(P4) JDK-8231431: JAOTC issues with JAR path containing spaces
(P4) JDK-8228674: LogCompilation: Improvements to log compare feature
(P4) JDK-8233783: Make 8232896 patch complete
(P4) JDK-8230742: Make AggressiveUnboxing a diagnostic flag
(P4) JDK-8229158: make UseSwitchProfiling non-experimental or false by-default
(P4) JDK-8226879: Memory leak in Type::hashcons
(P4) JDK-8233429: Minimal and zero VM build broken after JDK-8227003
(P4) JDK-8232083: Minimal VM is broken after JDK-8231586
(P4) JDK-8226721: Missing intrinsics for Math.ceil, floor, rint
(P4) JDK-8214239: Missing x86_64.ad patterns for clearing and setting long vector bits
(P4) JDK-8234248: More VectorSet cleanups
(P4) JDK-8193042: NativeLookup::lookup_critical_entry() should only load shared library once
(P4) JDK-8232162: Object reallocation in Deoptimization::fetch_unroll_info_helper should not depend on EliminateNestedLocks
(P4) JDK-8231471: Obsolete -XX:CompilationPolicyChoice
(P4) JDK-8225464: Obsolete TraceNMethodInstalls flag
(P4) JDK-8231460: Performance issue (CodeHeap) with large free blocks
(P4) JDK-8232165: Reduce allocations in ValueStack copying constructor
(P4) JDK-8071275: remove AbstractAssembler::update_delayed_values dead code
(P4) JDK-8235729: Shenandoah: Remove useless casting to non-constant
(P4) JDK-8231616: Simplify compilation policy hierarchy
(P4) JDK-8229254: solaris_x64 build fails after JDK-8191278
(P4) JDK-8219708: Stop flushing OSR nmethods earlier in the sweeper
(P4) JDK-8233820: Test crashed with assert(phi->operand_count() != 1 || phi->subst() != phi) failed: missed trivial simplification
(P4) JDK-8230459: Test failed to resume JVMCI CompilerThread
(P4) JDK-8233885: Test fails with assert(comp != __null) failed: Ensure we have a compiler
(P4) JDK-8230110: TestLinkageErrorInGenerateOopMap times out
(P4) JDK-8231376: Unproblem list compiler/unsafe/Unsafe{Off,On}HeapBooleanTest.java tests
(P4) JDK-8233035: Update JVMCI
(P4) JDK-8229352: Use of an uninitialized register in 32-bit ARM template interpreter
(P4) JDK-8233708: VectorSet cleanup
(P4) JDK-8234328: VectorSet::clear can cause fragmentation
(P4) JDK-8232896: ZGC: Enable C2 clone intrinsic
(P5) JDK-8233498: [SPARC] Remove dead code
(P5) JDK-8232873: Add missing test for 8220416
(P5) JDK-8232874: Add missing test for 8230062
(P5) JDK-8225644: C1 dumps incorrect class name in ClassCastException message
(P5) JDK-6394013: C2: Remove VerifyOpto
(P5) JDK-8232084: HotSpot build failed with GCC 9.2.1
(P5) JDK-8233193: Incorrect bailout from possibly_add_compiler_threads
(P5) JDK-8227632: Incorrect PrintCompilation message: made not compilable on levels 0 1 2 3 4
(P5) JDK-8225783: Incorrect use of binary operators on booleans in type.cpp
(P5) JDK-8227173: Minor cleanup of unused code in compile.hpp
(P5) JDK-8156207: Resource allocated BitMaps are often cleared unnecessarily
hotspot/gc:
(P1) JDK-8230642: 8224815 broke Shenandoah build
(P1) JDK-8231405: [Shenandoah] guarantee(d != NULL) failed: Null dominator info
(P1) JDK-8230214: AArch64 build failures after JDK-8229836 (Remove include of globals.hpp from allocation.hpp)
(P1) JDK-8234188: AIX build broken after 8220310
(P1) JDK-8229998: Build failure after JDK-8227054
(P1) JDK-8232674: Fix build and rename ShenandoahBarrierSet::oop_load_from_native_barrier
(P1) JDK-8229176: Shenandoah should acquire CodeCache_lock without safepoint check
(P1) JDK-8231583: Shenandoah: Fix register clash in SBSA::resolve_forwarding_pointer() borrowing
(P1) JDK-8232712: Shenandoah: SIGBUS in load_reference_barrier_native
(P1) JDK-8237776: Shenandoah: Wrong result with Lucene test
(P1) JDK-8229709: x86_32 build and test failures after JDK-8228369 (Shenandoah: Refactor LRB C1 stubs)
(P2) JDK-8235347: [Backout] 8235247: WorkerDataArray leaks C heap memory for associated work items
(P2) JDK-8235346: [Redo] 8235247: WorkerDataArray leaks C heap memory for associated work items
(P2) JDK-8235982: AArch64: Insufficient memory barriers in shadow region algorithm
(P2) JDK-8233232: AArch64: Shenandoah: jni_fast_GetLongField is broken
(P2) JDK-8234173: assert(loader != __null && oopDesc::is_oop(loader)) failed: loader must be oop
(P2) JDK-8235751: Assertion when triggering concurrent cycle during shutdown
(P2) JDK-8231395: Backout JDK-8231249
(P2) JDK-8230046: Build failure after JDK-8230003
(P2) JDK-8228420: compile error in shenandoahSupport.cpp with clang 9
(P2) JDK-8235305: Corrupted oops embedded in nmethods due to parallel modification during optional evacuation
(P2) JDK-8235324: Dying objects are published from users of CollectedHeap::object_iterate
(P2) JDK-8231579: G1's incremental calculation of region elapsed time always uses the same age group for prediction
(P2) JDK-8235669: G1: Stack walking API can expose AS_NO_KEEPALIVE oops
(P2) JDK-8235119: Incomplete initialization of scan_top values results in out-of-bounds scanning of regions
(P2) JDK-8229049: JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector
(P2) JDK-8237396: JvmtiTagMap::weak_oops_do() should not trigger barriers
(P2) JDK-8230215: MacOS debug build is broken after JDK-8230003
(P2) JDK-8233796: Shenandoah is broken after 8233708
(P2) JDK-8237369: Shenandoah: failed vmTestbase/nsk/jvmti/AttachOnDemand/attach021/TestDescription.java test
(P2) JDK-8236902: Shenandoah: Missing string dedup roots in all root scanner
(P2) JDK-8232176: Shenandoah: new assert in ShenandoahEvacuationTask is too strong
(P2) JDK-8230024: Shenandoah: remove unnecessary ShenandoahTimingConverter
(P2) JDK-8232778: Shenandoah: SBSA::arraycopy_prologue checks wrong register
(P2) JDK-8224881: Shenandoah: trashing "Collection Set, Pinned" region during Degenerated GC
(P2) JDK-8234662: Sweeper should keep current nmethod alive before yielding for ICStub refills
(P2) JDK-8234426: Sweeper should not CompiledIC::set_to_clean with ICStubs for is_unloading() nmethods
(P2) JDK-8229422: Taskqueue: Outdated selection of weak memory model platforms
(P2) JDK-8234508: VM_HeapWalkOperation::iterate_over_object reads non-strong fields with an on-strong load barrier
(P2) JDK-8236110: Windows (MSVC 2013) build failures after JDK-8233299
(P2) JDK-8235247: WorkerDataArray leaks C heap memory for associated work items
(P2) JDK-8235696: ZGC: assert(ZNMethod::is_armed(nm) == _should_disarm_nmethods) failed: Invalid state
(P2) JDK-8230566: ZGC: Don't substitute klass pointer during array clearing
(P2) JDK-8235366: ZGC: Kitchensink.java fails in ZBarrier::should_mark_through
(P2) JDK-8230565: ZGC: Redesign C2 load barrier to expand on the MachNode level
(P3) JDK-8235819: -Wformat-overflow is reported from GCC 9
(P3) JDK-8229420: [Redo] jstat reports incorrect values for OU for CMS GC
(P3) JDK-8213415: BitMap::word_index_round_up overflow problems
(P3) JDK-8230646: Epsilon does not extend TLABs to max size
(P3) JDK-8165443: Free Collection Set serial phase takes very long on large heaps
(P3) JDK-8087198: G1 card refinement: batching, sorting
(P3) JDK-8228609: G1 copy cost prediction uses used vs. actual copied bytes
(P3) JDK-8227434: G1 predictions may over/underflow with high variance input
(P3) JDK-8232533: G1 uses only a single thread for pretouching the java heap
(P3) JDK-8227671: G1: assert_used_and_recalculate_used_equal performs work in product builds
(P3) JDK-8217170: gc/arguments/TestUseCompressedOopsErgo.java timed out
(P3) JDK-8215523: jstat reports incorrect values for OU for CMS GC
(P3) JDK-8234208: Logging reports zero total refined cards under "Before GC RS summary"
(P3) JDK-8189737: Make HeapRegion not derive from Space
(P3) JDK-8230431: Move G1 trace code from gcTrace* to G1 directory
(P3) JDK-8233998: New young regions registered too early in collection set
(P3) JDK-8233065: PSParallelCompact::move_and_update is unused and should be removed
(P3) JDK-8229350: Shenandoah does not need barriers before CreateEx
(P3) JDK-8231244: Shenandoah: all-roots heap walking misses some weak roots
(P3) JDK-8230350: Shenandoah: Assertion failed when GC is cancelled by a worker thread
(P3) JDK-8232575: Shenandoah: asynchronous object/region pinning
(P3) JDK-8231410: Shenandoah: clone barrier should use base pointer
(P3) JDK-8230483: Shenandoah: consistently disable concurrent roots for Traversal mode
(P3) JDK-8236681: Shenandoah: Disable concurrent class unloading flag if no class unloading for the GC cycle
(P3) JDK-8234974: Shenandoah: Do concurrent roots even when no evacuation is necessary
(P3) JDK-8231198: Shenandoah: heap walking should visit all roots most of the time
(P3) JDK-8235842: Shenandoah: Implement native LRB for narrow oop
(P3) JDK-8231197: Shenandoah: JVMTI heap walking cleanup crashes with NULL forwardee
(P3) JDK-8237038: Shenandoah: Reduce thread pool size in TestEvilSyncBug.java test
(P3) JDK-8237392: Shenandoah: Remove unreliable assertion
(P3) JDK-8228490: Shenandoah: Shenandoah concurrent root evacuation may race against OopStorage::release()
(P3) JDK-8233500: Shenandoah: Shenandoah load barrier should save registers before calling keep alive barrier on x86
(P3) JDK-8236732: Shenandoah: Stricter placement for oom-evac scopes
(P3) JDK-8232802: Shenandoah: transition between "cset" and "pinned_cset" does not require cancelled gc
(P3) JDK-8231999: Shenandoah: Traversal failed compiler/jsr292/CallSiteDepContextTest.java
(P3) JDK-8235586: Shenandoah: Traversal GC still uses old CLD::oops_do API
(P3) JDK-8232730: Shenandoah: Traversal should not CAS the roots
(P3) JDK-8231293: Shenandoah: Traversal should not revive dead weak roots
(P3) JDK-8233165: Shenandoah:SBSA::gen_load_reference_barrier_stub() should use pointer register for address on aarch64
(P3) JDK-8233997: Some members of HeapRegion are not cleared in HeapRegion::hr_clear()
(P3) JDK-8048556: Unnecessary GCLocker-initiated young GCs
(P3) JDK-8229865: Use explicit #include debug.hpp for STATIC_ASSERT in gc/shenandoah/shenandoahUtils.cpp
(P3) JDK-8230706: Waiting on completion of strong nmethod processing causes long pause times with G1
(P3) JDK-8236936: x86_32 Minimal VM build failure after JDK-8230765
(P3) JDK-8234312: ZGC: Adjust warmup criteria
(P3) JDK-8227226: ZGC: Segmented array clearing
(P4) JDK-8228388: Add information about dirty/skipped card for Merge HCC in G1 log
(P4) JDK-8223575: add subspace transitions to gc+metaspace=info log lines
(P4) JDK-8227084: Add timing information for merge heap root preparation
(P4) JDK-8227089: Add timing information for merging humongous remembered sets
(P4) JDK-8227653: Add VM Global OopStorage
(P4) JDK-8226823: Adjust BarrierSetC2 for C2 runtime calls
(P4) JDK-8227637: Adjust Shenandoah C2 verifier to recognize IN_NATIVE barriers
(P4) JDK-8207800: always_do_update_barrier is unused
(P4) JDK-8227178: Backout of 8215523
(P4) JDK-8235551: BitMap::count_one_bits should use population_count
(P4) JDK-8229839: Break circular dependency between oop.inline.hpp and markWord.inline.hpp
(P4) JDK-8233597: Clean up code in G1Analytics::compute_pause_time_ratio
(P4) JDK-8233588: Clean up SurvRateGroup
(P4) JDK-8227168: Cleanup usage of NEW_C_HEAP_ARRAY
(P4) JDK-8235250: Create (test) abstraction for allocating objects that is immune to removal by optimizations
(P4) JDK-8230126: delay_to_keep_mmu can delay shutdown
(P4) JDK-8231553: Deprecate unused G1RSetScanBlockSize command line option
(P4) JDK-8221361: Eliminate two-phase initialization for PtrQueueSet classes
(P4) JDK-8162929: Enqueuing dirty cards into a single DCQS during GC does not scale
(P4) JDK-8232051: Epsilon should warn about Xms/Xmx/AlwaysPreTouch configuration
(P4) JDK-8235759: Extend GCConfig::is_gc_supported to mean supported not only included in build
(P4) JDK-8229020: Failure on CPUs allowing loads reordering: assert(_tasks[t] == 1) failed: What else?
(P4) JDK-8229169: False failure of GenericTaskQueue::pop_local on architectures with weak memory model
(P4) JDK-8231671: Fix copyright headers in hotspot (missing comma after year)
(P4) JDK-8228631: Fix inconsistent OopStorage::Block owner usage
(P4) JDK-8232588: G1 concurrent System.gc can return early or late
(P4) JDK-8232779: G1 current collection parallel time does not include optional evacuation
(P4) JDK-8227090: G1 does not account the OptMergeRS in cost per card calculation
(P4) JDK-8227719: G1 Pending cards estimation too conservative in cost prediction
(P4) JDK-8232776: G1 should always take rs_length_diff into account when predicting rs_lengths
(P4) JDK-8233279: G1: GCLocker GC with +GCLockerInvokesConcurrent spins while cycle in progress
(P4) JDK-8231242: G1CollectedHeap::print_regions_on() does not print description for "OA" and "CA" regions
(P4) JDK-8230332: G1DirtyCardQueueSet _notify_when_complete is always true
(P4) JDK-8230109: G1DirtyCardQueueSet should use card counts rather than buffer counts
(P4) JDK-8229044: G1RedirtyCardsQueueSet should be local to a collection
(P4) JDK-8232232: G1RemSetSummary::_rs_threads_vtimes is not initialized to zero
(P4) JDK-8209802: Garbage collectors should register JFR types themselves to avoid build errors.
(P4) JDK-8226822: GC interface for C1 runtime calls
(P4) JDK-8227224: GenCollectedHeap: add subspace transitions for young gen for gc+heap=info log lines
(P4) JDK-8230765: Implement nmethod barrier for x86_32 platforms
(P4) JDK-8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector
(P4) JDK-8233301: Implementation of JEP 366: Deprecate the ParallelScavenge + SerialOld GC Combination
(P4) JDK-8233299: Implementation: JEP 365: ZGC on Windows
(P4) JDK-8220312: Implementation: NUMA-Aware Memory Allocation for G1, Logging (3/3)
(P4) JDK-8220310: Implementation: NUMA-Aware Memory Allocation for G1, Mutator (1/3)
(P4) JDK-8220311: Implementation: NUMA-Aware Memory Allocation for G1, Survivor (2/3)
(P4) JDK-8230794: Improve assert to get more information about the JDK-8227695 failure
(P4) JDK-8231153: Improve concurrent refinement statistics
(P4) JDK-8229278: Improve hs_err location printing to assume less about GC internals
(P4) JDK-8213108: Improve work distribution during remembered set scan
(P4) JDK-8235341: Improve WorkerDataArray API to disallow separate instantiation of sub-items
(P4) JDK-8233919: Incrementally calculate the occupied cards in a heap region remembered set
(P4) JDK-8233702: Introduce helper function to clamp value to range
(P4) JDK-8204951: Investigate to use WorkGang for Parallel GC
(P4) JDK-8210473: JEP 345: NUMA-Aware Memory Allocation for G1
(P4) JDK-8229358: JEP 364: ZGC on macOS (Experimental)
(P4) JDK-8232364: JEP 365: ZGC on Windows (Experimental)
(P4) JDK-8229492: JEP 366: Deprecate the ParallelScavenge + SerialOld GC Combination
(P4) JDK-8234822: Limit ZGC jtreg-support to Windows 2019 Server
(P4) JDK-8233073: Make BitMap accessors more memory ordering friendly
(P4) JDK-8230327: Make G1DirtyCardQueueSet free-id init unconditional
(P4) JDK-8234000: Make HeapRegion::bottom/end/hrm_index const
(P4) JDK-8225255: Make SATB qset lock-free
(P4) JDK-8229127: Make some methods in the allocation path non-virtual
(P4) JDK-8227442: Make young_index_in_cset zero-based
(P4) JDK-8227739: Merge cost predictions for scanning cards and log buffer entries
(P4) JDK-8235262: Move c2i_entry_barrier for x86_32 to shared
(P4) JDK-8234179: Move HeapRegion::_recorded_rs_length/_predicted_elapsed_time_ms into G1CollectionSet
(P4) JDK-8226232: Move merge heap roots code out from G1RemSetScanState
(P4) JDK-8227927: Move ParallelCleaningTask back to G1
(P4) JDK-8227755: Need more than 2 distinct CodeCache unloading cycles
(P4) JDK-8233029: Obsolete flag GCTaskTimeStampEntries
(P4) JDK-8225776: Optimize branch frequency of G1's write post-barrier in C2
(P4) JDK-8224741: Optimize the scan area during the Scan Heap Roots phase
(P4) JDK-8224659: Parallel GC: Use WorkGang (1: PCRefProcTask)
(P4) JDK-8224660: Parallel GC: Use WorkGang (2: MarksFromRootsTask)
(P4) JDK-8224661: Parallel GC: Use WorkGang (3: UpdateDensePrefixAndCompactionTask)
(P4) JDK-8224662: Parallel GC: Use WorkGang (4: SharedRestorePreservedMarksTaskExecutor)
(P4) JDK-8224663: Parallel GC: Use WorkGang (5: ScavengeRootsTask)
(P4) JDK-8224664: Parallel GC: Use WorkGang (6: PSRefProcTaskProxy)
(P4) JDK-8224665: Parallel GC: Use WorkGang (7: remove task manager)
(P4) JDK-8224666: Parallel GC: Use WorkGang (8: obsolete and remove flags)
(P4) JDK-8227225: ParallelGC: add subspace transitions for young gen for gc+heap=info log lines
(P4) JDK-8141637: Parallelize single threaded heap region iteration during Pre Evacuate Collection Set
(P4) JDK-8226796: Reduce debug level logging for oopstorage+blocks
(P4) JDK-8230404: Refactor logged card refinement support in G1DirtyCardQueueSet
(P4) JDK-8230808: Remove Access::equals()
(P4) JDK-8230796: Remove BarrierSet::oop_equals_operator_allowed()
(P4) JDK-8159984: Remove call to ClassLoaderDataGraph::clear_claimed_marks during the initial mark pause
(P4) JDK-8231051: Remove check_obj_alignment() and replace with is_object_aligned()
(P4) JDK-8231113: Remove CollectedHeap::check_oop_location()
(P4) JDK-8234437: Remove CollectedHeap::safe_object_iterate()
(P4) JDK-8231117: Remove G1EvacuationRootClosures::raw_strong_oops()
(P4) JDK-8230372: Remove G1GCPhaseTimes::MergeLBProcessedBuffers
(P4) JDK-8230562: Remove g1HeapSizingPolicy_ext.cpp
(P4) JDK-8233280: Remove GCLockerInvokesConcurrent
(P4) JDK-8224815: Remove non-GC uses of CollectedHeap::is_in_reserved()
(P4) JDK-8230398: Remove NULL checks before FREE_C_HEAP_ARRAY
(P4) JDK-8231946: Remove obsolete and unused ShenandoahVerifyObjectEquals flag
(P4) JDK-8230841: Remove oopDesc::equals()
(P4) JDK-8231956: Remove seq_add_card/reference from PerRegionTable class
(P4) JDK-8225743: Remove ShenandoahBarrierSetC2::escape_is_barrier_node and related GC interface
(P4) JDK-8234438: Remove some CMS leftovers
(P4) JDK-8235427: Remove unnecessary parameters from G1CollectedHeap::free_region and HeapRegion::hr_clear
(P4) JDK-8225779: Remove unused CollectedHeap::cell_header_size()
(P4) JDK-8215166: Remove unused G1PretouchAuxiliaryMemory option
(P4) JDK-8228503: Rename "rs_lengths" to "rs_length" in ergo code
(P4) JDK-8232777: Rename G1Policy::_max_rs_length as it is no maximum
(P4) JDK-8230192: Rename G1RedirtyCardsBufferList to G1BufferNodeList
(P4) JDK-8234574: Rename prediction methods in G1Analytics
(P4) JDK-8235757: Rename SupportedGC to IncludedGC
(P4) JDK-8234586: Rename survRateGroup.?pp files to g1SurvRateGroup.?pp
(P4) JDK-8066774: Rename the annotations arrays names in ClassFileParser
(P4) JDK-8234587: Rename the SurvRateGroup class to G1SurvRateGroup
(P4) JDK-8231189: Rename worker_i parameters to worker_id
(P4) JDK-8230203: Replace markWord enums with typed constants
(P4) JDK-8226793: Replace OopStorage dup_name with os::strdup
(P4) JDK-8232771: Revert JDK-8230794 because of environment changes
(P4) JDK-8229258: Rework markOop and markOopDesc into a simpler mark word value carrier
(P4) JDK-8226913: Scale cards per chunk used during heap root scanning with region size
(P4) JDK-8226797: serviceability/tmtools/jstat/GcCapacityTest.java fails with Exception: java.lang.RuntimeException: OGCMN > OGCMX (min generation capacity > max generation capacity)
(P4) JDK-8227053: ServiceThread cleanup of OopStorage is missing some
(P4) JDK-8227054: ServiceThread needs to know about all OopStorage objects
(P4) JDK-8230425: Shenandoah forces +UseNUMAInterleaving even after explicitly disabled
(P4) JDK-8227039: Shenandoah: Aggressive heuristics for Traversal mode
(P4) JDK-8229213: Shenandoah: Allow VM global oop storage to be processed concurrently
(P4) JDK-8232729: Shenandoah: assert ShenandoahHeap::cas_oop addresses are aligned
(P4) JDK-8231324: Shenandoah: avoid duplicated weak root works during final traversal
(P4) JDK-8233574: Shenandoah: build is broken without jfr
(P4) JDK-8232008: Shenandoah: C1 load barrier does not match interpreter version
(P4) JDK-8232009: Shenandoah: C2 load barrier does not match interpreter version
(P4) JDK-8227677: Shenandoah: C2: Make in-native LRB special case of normal LRB
(P4) JDK-8233339: Shenandoah: Centralize load barrier decisions into ShenandoahBarrierSet
(P4) JDK-8233337: Shenandoah: Cleanup AArch64 SBSA::load_reference_barrier_not_null()
(P4) JDK-8232573: Shenandoah: cleanup and add more logging for in-pause phases
(P4) JDK-8229474: Shenandoah: Cleanup CM::update_roots()
(P4) JDK-8229419: Shenandoah: Cleanup LRB strength selector code
(P4) JDK-8231947: Shenandoah: cleanup ShenandoahHumongousMoves flag treatment
(P4) JDK-8232908: Shenandoah: compact heuristics has incorrect trigger "Free is lower than allocated recently"
(P4) JDK-8231447: Shenandoah: Compilation-time regression after JDK-8231086
(P4) JDK-8231932: Shenandoah: conc/par GC threads ergonomics overrides user settings
(P4) JDK-8226241: Shenandoah: Concurrent class unloading
(P4) JDK-8226310: Shenandoah: Concurrent evacuation of CLDG
(P4) JDK-8226311: Shenandoah: Concurrent evacuation of OopStorage backed weak roots
(P4) JDK-8232747: Shenandoah: Concurrent GC should deactivate SATB before processing weak roots
(P4) JDK-8229416: Shenandoah: Demote or remove ShenandoahOptimize*Final optimizations
(P4) JDK-8233520: Shenandoah: do not sleep when thread is attaching
(P4) JDK-8235260: Shenandoah: Don't allow recycle-assist until concurrent roots are done
(P4) JDK-8225582: Shenandoah: Enable concurrent evacuation of JNIHandles
(P4) JDK-8235685: Shenandoah: Enable leak profiler
(P4) JDK-8225483: Shenandoah: Enhance native access barrier
(P4) JDK-8225573: Shenandoah: Enhance ShenandoahVerifier to ensure roots to-space invariant
(P4) JDK-8227327: Shenandoah: Faster and more parallel tests
(P4) JDK-8229470: Shenandoah: Fix C1 getAndSetObject() failure
(P4) JDK-8235337: Shenandoah: Fix evac OOM scoping for concurrent class unloading
(P4) JDK-8231667: Shenandoah: Full GC should take empty regions into slices for compaction
(P4) JDK-8231249: Shenandoah: GC retries are too aggressive for tests that expect OOME
(P4) JDK-8232534: Shenandoah: guard against reentrant ShenandoahHeapLock locking
(P4) JDK-8228532: Shenandoah: Implement SBSA::try_resolve_jobject_in_native()
(P4) JDK-8232992: Shenandoah: Implement self-fixing interpreter LRB
(P4) JDK-8232010: Shenandoah: implement self-fixing native barrier
(P4) JDK-8228720: Shenandoah: Implementation of concurrent class unloading
(P4) JDK-8226757: Shenandoah: Make traversal and passive modes explicit
(P4) JDK-8229921: Shenandoah: Make Traversal mode non-experimental
(P4) JDK-8232205: Shenandoah: missing "Update References" -> "Update Roots" tracing
(P4) JDK-8229002: Shenandoah: Missing node types in ShenandoahLoadReferenceBarrier::needs_barrier_impl()
(P4) JDK-8227676: Shenandoah: More consistent naming of LRB runtime entry points
(P4) JDK-8226586: Shenandoah: No need to pre-evacuate roots for degenerated GC
(P4) JDK-8232791: Shenandoah: passive mode should disable pacing
(P4) JDK-8233387: Shenandoah: passive mode should disable pacing ergonomically
(P4) JDK-8225550: Shenandoah: Prevent SH::object_iterate() call's side-effects
(P4) JDK-8232102: Shenandoah: print everything in proper units
(P4) JDK-8228369: Shenandoah: Refactor LRB C1 stubs
(P4) JDK-8225590: Shenandoah: Refactor ShenandoahClassLoaderDataRoots API
(P4) JDK-8233401: Shenandoah: Refactor/cleanup Shenandoah load barrier code
(P4) JDK-8226957: Shenandoah: Remove obsoleted "ShenandoahStoreCheck" option
(P4) JDK-8227199: Shenandoah: Remove superfluous calls to can_do_traversal_gc()
(P4) JDK-8228364: Shenandoah: Remove unused code from ShenandoahBarrierSetC1
(P4) JDK-8228775: Shenandoah: Remove useless null-input-verification in Shenandoah/C2 verifier
(P4) JDK-8235355: Shenandoah: Resolve deadlock between OOM handler and nmethod lock
(P4) JDK-8229977: Shenandoah: save/restore FPU state aroud LRB runtime call
(P4) JDK-8233021: Shenandoah: SBSC2::is_shenandoah_lrb_call should match all LRB shapes
(P4) JDK-8231087: Shenandoah: Self-fixing load reference barriers for C1/C2
(P4) JDK-8226413: Shenandoah: Separate root scanner for SH::object_iterate()
(P4) JDK-8227635: Shenandoah: SHBSA::load_at() needs to deal IN_NATIVE load
(P4) JDK-8235776: Shenandoah: Shenandoah root updater not always uses right code blob closure
(P4) JDK-8233850: Shenandoah: Shenandoah thread count ergonomics should be container aware
(P4) JDK-8229206: Shenandoah: ShenandoahWeakRoot::oops_do() uses wrong timing phase
(P4) JDK-8227866: Shenandoah: Split weak root processing and class unloading in parallel cleaning task
(P4) JDK-8234768: Shenandoah: Streamline enqueueing runtime barriers
(P4) JDK-8222766: Shenandoah: streamline post-LRB CAS barrier (x86)
(P4) JDK-8231086: Shenandoah: Stronger invariant for object-arraycopy
(P4) JDK-8231250: Shenandoah: Traversal GC should keep alive weak load from heap
(P4) JDK-8235598: Shenandoah: Update copyrights
(P4) JDK-8227101: Shenandoah: Use ShenandoahSharedFlag for claimed flag in ShenandoahSerialRoot
(P4) JDK-8233303: Shenandoah: verifier assert erroneously uses byte_size_in_exact_unit
(P4) JDK-8226695: Shenandoah: Wire C1 and C2 IN_NATIVE barrier
(P4) JDK-8233306: Sort members in G1's HeapRegion after removal of Space dependency
(P4) JDK-8229919: Support JNI Critical functions in object pinning API on x86_32 platforms
(P4) JDK-8227179: Test for new gc+metaspace=info output format
(P4) JDK-8227086: Use AS_NO_KEEPALIVE loads in HeapDumper
(P4) JDK-8220465: Use shadow regions for faster ParallelGC full GCs
(P4) JDK-8230730: UseCompressedOops test crash with assertion failure
(P4) JDK-8232649: ZGC: Add callbacks to ZMemoryManager
(P4) JDK-8232650: ZGC: Add initialization hooks for OS specific code
(P4) JDK-8230758: ZGC: Add missing precompiled include and fix friend declaration
(P4) JDK-8227085: ZGC: Add on_weak load barrier verification
(P4) JDK-8229135: ZGC: Adding missing ZStatTimerDisable before call to ZVerify::roots_strong()
(P4) JDK-8234010: ZGC: Change ZResurrection to use Atomic::load/store
(P4) JDK-8230092: ZGC: Consolidate ZBackingFile, ZBackingPath and ZPhysicalMemoryBacking on Linux
(P4) JDK-8234379: ZGC: Do not resize TLABs unless -XX:ResizeTLAB is enabled
(P4) JDK-8231943: ZGC: Enable serviceability/dcmd/gc/RunGCTest
(P4) JDK-8234573: ZGC: Enable ZVerifyMarking by default in debug builds
(P4) JDK-8233061: ZGC: Enforce memory ordering in segmented bit maps
(P4) JDK-8231563: ZGC: Fails to warn when user sets the max heap size to larger than 16TB
(P4) JDK-8231776: ZGC: Fix incorrect address space description
(P4) JDK-8229129: ZGC: Fix incorrect format string for doubles
(P4) JDK-8229406: ZGC: Fix incorrect statistics
(P4) JDK-8230759: ZGC: Fix integer types
(P4) JDK-8231251: ZGC: Fix ZHeap includes
(P4) JDK-8232001: ZGC: Ignore metaspace GC threshold until GC is warm
(P4) JDK-8235760: ZGC: Implement precise check for @require vm.gc.Z for Windows
(P4) JDK-8230845: ZGC: Implement ZLock using os::PlatformMutex
(P4) JDK-8224817: ZGC: Implementation of JEP 364: ZGC on macOS
(P4) JDK-8234338: ZGC: Improve small heap usage
(P4) JDK-8233793: ZGC: Incorrect type used in ZBarrierSetC2 clone_type()
(P4) JDK-8232239: ZGC: Inline ZCPU::count() and ZCPU:id()
(P4) JDK-8230090: ZGC: Introduce ZSyscall
(P4) JDK-8219724: ZGC: Make inline cache cleaning more robust
(P4) JDK-8229451: ZGC: Make some roots invisible to the heap iterator
(P4) JDK-8230307: ZGC: Make zGlobals and zArguments OS agnostic
(P4) JDK-8232602: ZGC: Make ZGranuleMap ZAddress agnostic
(P4) JDK-8230846: ZGC: Make ZUtils::alloc_aligned() posix-specific
(P4) JDK-8232604: ZGC: Make ZVerifyViews mapping and unmapping precise
(P4) JDK-8231266: ZGC: Minor cleanups in ZCollectedHeap and ZHeap
(P4) JDK-8232648: ZGC: Move ATTRIBUTE_ALIGNED to the front of declarations
(P4) JDK-8234361: ZGC: Move heuristics code in ZWorker to ZHeuristics
(P4) JDK-8234009: ZGC: Move resurrection unblock to before the _unload.purge() call
(P4) JDK-8232237: ZGC: Move ZArray inline funtions to zArray.inline.hpp
(P4) JDK-8232238: ZGC: Move ZList inline funtions to zList.inline.hpp
(P4) JDK-8232236: ZGC: Move ZThread inline funtions to zThread.inline.hpp
(P4) JDK-8232235: ZGC: Move ZValue inline funtions to zValue.inline.hpp
(P4) JDK-8234654: ZGC: Only disarm NMethods when marking/relocating code roots
(P4) JDK-8234543: ZGC: Parallel pre-touch
(P4) JDK-8232601: ZGC: Parameterize the ZGranuleMap table size
(P4) JDK-8231940: ZGC: Print correct low/high capacity
(P4) JDK-8231552: ZGC: Refine address space reservation
(P4) JDK-8230756: ZGC: Remove redundant memset in ZStatValue
(P4) JDK-8232116: ZGC: Remove redundant ZLock in ZNMethodTable
(P4) JDK-8230096: ZGC: Remove unused ZObjectAllocator::_nworkers
(P4) JDK-8229128: ZGC: Remove unused ZThreadRootsIterator
(P4) JDK-8232070: ZGC: Remove unused ZVerifyLoadBarriers
(P4) JDK-8235748: ZGC: Remove ZAddress::address()
(P4) JDK-8231270: ZGC: Remove ZAddressSpace* and ZAddressReserved*
(P4) JDK-8231825: ZGC: Remove ZMaxHeapSize and ZMaxHeapSizeShift
(P4) JDK-8231996: ZGC: Replace ZStatisticsForceTrace with check if JFR event is enabled
(P4) JDK-8230661: ZGC: Stop reloading oops in load barriers
(P4) JDK-8224820: ZGC: Support discontiguous heap reservations
(P4) JDK-8233797: ZGC: Unify naming convention for functions using atomics
(P4) JDK-8230878: ZGC: Use THREAD_LOCAL instead of __thread
(P4) JDK-8229017: ZGC: Various cleanups of ZVerify
(P4) JDK-8231296: ZGC: vmTestbase/nsk/jvmti/Allocate/alloc001/ fails
(P4) JDK-8234602: ZGC: Windows compile error in ZHeuristic
(P4) JDK-8228657: ZGC: ZObjectAllocator::used() should take undone allocations into account
(P4) JDK-8231774: ZGC: ZVirtualMemoryManager unmaps incorrect address
(P5) JDK-8043505: G1RemSet::_conc_refine_cards is incremented unsynchronized
(P5) JDK-8232260: Remove g1 prefix in G1CollectedHeap::g1_hot_card_cache() getter
(P5) JDK-8229835: Shenandoah should recommend -Xlog:safepoint+stats
hotspot/jfr:
(P2) JDK-8229437: assert(is_aligned(ref, HeapWordSize)) failed: invariant
(P2) JDK-8231025: Incorrect method tag offset for big endian platform
(P2) JDK-8232905: JFR fails with assertion: assert(t->unflushed_size() == 0) failed: invariant
(P2) JDK-8236743: JFR: assert(klass != __null) failed: invariant in ObjectSampleCheckpoint::add_to_leakp_set
(P2) JDK-8236691: JFR: assert((((((klass)->trace_id()) & ((JfrTraceIdEpoch::method_and_class_in_use_this_epoch_bits()))) != 0))) failed: invariant
(P2) JDK-8234059: Stress test fails with "Unexpected Exception in thread JFR Event Stream"
(P3) JDK-8216041: [Event Request] - Deoptimization
(P3) JDK-8225694: Destination option missing in FlightRecorderMXBeanImpl
(P3) JDK-8233111: Epoch shift synchronization point for Compiler threads
(P3) JDK-8233700: EventStream not closed
(P3) JDK-8234888: EventStream::close doesn't abort streaming thread
(P3) JDK-8230767: FlightRecorderListener returns null recording
(P3) JDK-8226511: Implement JFR Event Streaming
(P3) JDK-8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing
(P3) JDK-8184193: JEP 349: JFR Event Streaming
(P3) JDK-8234671: JFR api/consumer/recordingstream/TestStart.java failed due to timeout at testStartTwice()
(P3) JDK-8234684: JFR crashes when rotating the JFR output during assertion failure
(P3) JDK-8236487: JFR Recorder Thread crashed due to "assert(_chunkwriter.is_valid()) failed: invariant"
(P3) JDK-8223697: jfr tool can't format duration values greater than 1 minute
(P3) JDK-8233416: JFR: assert((((((klass)->trace_id()) & (((1 << 1) << 8) | (JfrTraceIdEpoch::in_use_this_epoch_bit()))) != 0))) failed: invariant
(P3) JDK-8235390: JfrEmergencyDump::on_vm_shutdown crashes
(P3) JDK-8230400: Missing constant pool entry for a method in stacktrace
(P3) JDK-8221485: Not all options for JFR.dump are documented
(P3) JDK-8225797: OldObjectSample event creates unexpected amount of checkpoint data
(P3) JDK-8234060: Potential memory reordering problem in JfrBuffer flush mechanism
(P3) JDK-8236263: Remove experimental streaming events
(P3) JDK-8236264: Remove jdk.jfr.Recording::setFlushInterval and jdk.jfr.Recording::getFlushInterval
(P3) JDK-8231081: TestMetadataRetention fails due to missing symbol id
(P3) JDK-8227411: TestTimeMultiple.java failed "assert(!lease()) failed: invariant"
(P3) JDK-8234433: TestUnloadEventClassCount fails with "assert(SafepointSynchronize::is_at_safepoint()) failed: invariant"
(P4) JDK-8231922: Could not find field with name revokedClass
(P4) JDK-8229189: Improve JFR leak profiler tracing to deal with discontiguous heaps
(P4) JDK-8219082: jdk/jfr/event/runtime/TestShutdownEvent.java failed in validateStackTrace()
(P4) JDK-8231317: jdk/jfr/jcmd/TestJcmdConfigure.java fails with "java.lang.RuntimeException: assertTrue: expected true, was false"
(P4) JDK-8233075: JFR - nmetods - misspelled in several places
(P4) JDK-8233375: JFR emergency dump does not recover thread state
(P4) JDK-8235654: JFR leak profiler should not trace through the StringTable
(P4) JDK-8233870: JFR TestSetEndTime.java times out - onClose() is never called
(P4) JDK-8230888: jfrVirtualMemory.cpp should include globals.hpp
(P4) JDK-8232594: Make the output of the JFR command duration more user friendly
(P4) JDK-8226897: Provide object age with JFR OldObjectSample event
(P4) JDK-8216565: Specifying the same path creates a new directory in JFR.configure
(P4) JDK-8234383: Test TestBiasedLockRevocationEvents.java assumes -XX:UseBiasedLocking is enabled
(P4) JDK-8235174: ZGC: Add support for JFR leak profiler
hotspot/jvmti:
(P1) JDK-8232046: AArch64 build failure after JDK-8225681
(P2) JDK-8232056: GetOwnedMonitorInfoWithEATest.java fails with ZGC: Heap too small
(P2) JDK-8235829: graal crashes with Zombie.java test
(P3) JDK-8228547: accessibility errors in jvmti.html
(P3) JDK-8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving NULL _value"
(P3) JDK-8173658: JvmtiExport::post_class_unload() is broken for non-JavaThread initiators
(P3) JDK-8236124: Minimal VM slowdebug build failed after JDK-8212160
(P3) JDK-8221372: Test vmTestbase/nsk/jvmti/GetThreadState/thrstat001/TestDescription.java times out
(P3) JDK-8173361: various crashes in JvmtiExport::post_compiled_method_load
(P3) JDK-8225681: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine fails due to a) MT-unsafe modification of inline cache
(P4) JDK-8228596: Class redefinition fails when condy instructions are removed
(P4) JDK-8231737: Cleanup JvmtiRawMonitor code
(P4) JDK-8231289: Disentangle JvmtiRawMonitor from ObjectMonitor and clean it up
(P4) JDK-8169467: GetLocalInstance returns JVMTI_ERROR_TYPE_MISMATCH (rather than JVMTI_ERROR_INVALID_SLOT) on static method
(P4) JDK-8227738: jvmti/DataDumpRequest/datadumpreq001 failed due to "exit code is 134"
(P4) JDK-8227563: jvmti/scenarios/contention/TC05/tc05t001 fails due to "ERROR: tc05t001.cpp, 278: (waitedThreadCpuTime - waitThreadCpuTime) < (EXPECTED_ACCURACY * 1000000)"
(P4) JDK-8225437: JvmtiExport::gc_epilogue is unnecessary
(P4) JDK-8231567: minimal build failed after JDK-8226690
(P4) JDK-8235218: Minimal VM is broken after JDK-8173361
(P4) JDK-8235456: Minimal VM is broken after JDK-8212160
(P4) JDK-8235273: nmethodLocker not needed for COMPILED_METHOD_UNLOAD events
(P4) JDK-8212959: Remove testing against NSK_FALSE/NSK_TRUE from tests in vmTestbase
(P4) JDK-8228998: Remove the testing against NSK_FALSE from tests
(P4) JDK-8229036: Remove the testing against NSK_TRUE from tests
(P4) JDK-8226690: SIGSEGV in MetadataOnStackClosure::do_metadata
(P4) JDK-8235280: UnProblemList vmTestbase/nsk/jvmti/GetThreadState/thrstat001/TestDescription.java
(P5) JDK-8230830: No required ResourceMark in src/hotspot/share/prims/jvmtiImpl.cpp:JvmtiSuspendControl::print()
hotspot/runtime:
(P1) JDK-8231375: AArch64 build failure after JDK-8230505
(P1) JDK-8234324: ARM32 build broken after 8231610
(P1) JDK-8234133: VM build broken due to memory/archiveUtils.inline.hpp: No such file or directory
(P1) JDK-8231930: Windows build fails after JDK-8191521
(P2) JDK-8231612: 100% cpu on arm32 in Service Thread
(P2) JDK-8230118: 32-bit build failures after JDK-8227054
(P2) JDK-8232150: aarch64 build broken after JDK-8232050
(P2) JDK-8233695: AArch64 build failures after -Wno-extra removal
(P2) JDK-8233599: ARM32 Build failed due to 8232050 missing an include
(P2) JDK-8232921: assert(is_object_aligned(result)) failed: address not aligned
(P2) JDK-8234355: Buffer overflow in jcmd GC.class_stats due to too many classes
(P2) JDK-8235325: build failure on Linux after 8235243
(P2) JDK-8229202: Docker reporting causes secondary crashes in error handling
(P2) JDK-8233698: GCC 4.8.5 build failure after JDK-8233530
(P2) JDK-8229345: Memory leak due to vtable stubs not being shared on SPARC
(P2) JDK-8233608: Minimal build broken after JDK-8233494
(P2) JDK-8226967: Minimal VM: FALSE was not declared in this scope
(P2) JDK-8227117: normal interpreter table is not restored after single stepping with TLH
(P2) JDK-8230294: runtime/cds/appcds/ClassPathAttr.java failed with jar operation failed
(P2) JDK-8233137: runtime/ErrorHandling/VeryEarlyAssertTest.java fails after 8232080
(P2) JDK-8227582: runtime/TLS/testtls.sh fails on x86_32
(P2) JDK-8230317: serviceability/sa/ClhsdbPrintStatics.java fails after 8230184
(P2) JDK-8086003: Test fails on OSX with java.lang.RuntimeException 'Narrow klass base: 0x0000000000000000, Narrow klass shift: 3' missing
(P2) JDK-8228855: Test runtime/CommandLine/OptionsValidation/TestOptionsWithRanges fails after JDK-8227123
(P2) JDK-8235515: TestBasicLogOutput.java crashes due to EXCEPTION_ACCESS_VIOLATION in HandshakeThreadsOperation::do_handshake
(P2) JDK-8231058: VerifyOops crashes with assert(_offset >= 0) failed: offset for non comment?
(P3) JDK-8226699: [BACKOUT] JDK-8221734 Deoptimize with handshakes
(P3) JDK-8234270: [REDO] JDK-8204128 NMT might report incorrect numbers for Compiler area
(P3) JDK-8229925: [s390, PPC64] Exception check missing in interpreter
(P3) JDK-8236555: [s390] Fix VerifyOops
(P3) JDK-8235849: Add back deprecation warning in jcmd man page
(P3) JDK-8232118: Add JVM option to enable JVMCI compilers in product mode
(P3) JDK-8234397: add OS uptime information to os::print_os_info output
(P3) JDK-8228902: add os::dll_load to the unified logging os category
(P3) JDK-8213150: Add verification for locking by VMThread
(P3) JDK-8227631: Adjust AIX version check
(P3) JDK-8224137: Analyze and port invocation tests to jtreg and co-locate to jdk repo
(P3) JDK-8235490: AppCDS DynamicArchiveRelocationTest.java failed: 'always map archive(s) at an alternative address' missing
(P3) JDK-8234429: appcds/dynamicArchive tests crashing with Graal
(P3) JDK-8211723: AppCDS: referring to a jar file in any way other than exactly how it was done during dumping doesn't work
(P3) JDK-8228758: assert(_no_handle_mark_nesting == 0) failed: allocating handle inside NoHandleMark
(P3) JDK-8222446: assert(C->env()->system_dictionary_modification_counter_changed()) failed: Must invalidate if TypeFuncs differ
(P3) JDK-8227123: Assertion failure when setting SymbolTableSize larger than 2^17 (131,072)
(P3) JDK-8191890: Biased locking still uses the inferior stop the world safepoint for revocation
(P3) JDK-8234798: Build failure after atomic changes in JDK-8234563
(P3) JDK-8232120: com/sun/jdi/InvokeTest fails with -Xcheck:jni: assert(k->is_instance_klass()) failed: cast to InstanceKlass
(P3) JDK-8228753: Deprecate -XX:FieldsAllocationStyle product option
(P3) JDK-8228749: Deprecate product flag -XX:CompactFields
(P3) JDK-8233078: fix minimal VM build on Linux ppc64(le)
(P3) JDK-8231885: Fix/remove malformed assert in os_windows.cpp
(P3) JDK-8191521: handle long relative path specified in -Xbootclasspath/a on windows
(P3) JDK-8235489: handle return values of sscanf calls in hotspot
(P3) JDK-8230674: Heap dumps should exclude dormant CDS archived objects of unloaded classes
(P3) JDK-8232030: HelloDynamic.java fails with latest Graal
(P3) JDK-8226525: HotSpot compile-time error for x86-32
(P3) JDK-8223173: Implement fast class initialization checks on AARCH64
(P3) JDK-8236617: jtreg test containers/docker/TestMemoryAwareness.java fails after 8226575
(P3) JDK-8226798: JVM crash in klassItable::initialize_itable_for_interface(int, InstanceKlass*, bool, Thread*)
(P3) JDK-8228485: JVM crashes when bootstrap method for condy triggers loading of class whose static initializer throws exception
(P3) JDK-8231162: JVMTI RawMonitorWait triggers assertion failure: Only JavaThreads can be interruptible
(P3) JDK-8232112: MDO extra_data_lock leaks during class unloading
(P3) JDK-8232571: new sun.misc.Signal("INFO") throws IllegalArgumentException since JDK11
(P3) JDK-8204128: NMT might report incorrect numbers for Compiler area
(P3) JDK-8215355: Object monitor deadlock with no threads holding the monitor (using jemalloc 5.1)
(P3) JDK-8231610: Relocate the CDS archive if it cannot be mapped to the requested address
(P3) JDK-8225782: Remove expired flags in JDK 14
(P3) JDK-8234058: runtime/CompressedOops/CompressedClassPointers.java fails with 'Narrow klass base: 0x0000000000000000' missing from stdout/stderr
(P3) JDK-8229778: TestJstatdDefaults.java failed due to "fatal error: LEAF method calling lock?"
(P3) JDK-8233549: Thread interrupted state must only be accessed when not in a safepoint-safe state
(P3) JDK-8235869: Update Java manpage for JDK 14
(P3) JDK-8186988: use log_warning() and log_error() instead of tty->print_cr for CDS warning and error messages
(P3) JDK-8227275: Within native OOM error handling, assertions may hang the process
(P4) JDK-8234897: 8234748: Clean up atomic and orderAccess includes - part 2
(P4) JDK-8234274: [BACKOUT] JDK-8204128 NMT might report incorrect numbers for Compiler area
(P4) JDK-8230385: [cds] No message is logged when shared image cannot be used due to mismatched configuration
(P4) JDK-8227597: [fastdbg build] Arena::inc_bytes_allocated should get inlined
(P4) JDK-8227006: [linux] Runtime.availableProcessors execution time increased by factor of 100
(P4) JDK-8228743: [PPC64, s390] Implement FastJNIAccessors
(P4) JDK-8231949: [PPC64, s390]: Make async profiling more reliable
(P4) JDK-8226705: [REDO] Deoptimize with handshakes
(P4) JDK-8232005: [s390, PPC64] More exception checks missing in interpreter
(P4) JDK-8231606: _method_ordering is not set during CDS dynamic dump time
(P4) JDK-8231841: AArch64: debug.cpp help() is missing an AArch64 line for pns
(P4) JDK-8233912: aarch64: minor improvements of atomic operations
(P4) JDK-8233839: aarch64: missing memory barrier in NewObjectArrayStub and NewTypeArrayStub
(P4) JDK-8228725: AArch64: Purge method call format support
(P4) JDK-8233466: aarch64: remove unnecessary load of mdo when profiling return and parameters type
(P4) JDK-8218628: Add detailed message to NullPointerException describing what is null.
(P4) JDK-8233359: Add global sized operator delete definitions
(P4) JDK-8232651: Add implementation of os::processor_id() for Windows
(P4) JDK-8232060: add some initializations using sigemptyset in os_aix.cpp
(P4) JDK-8227630: adjust format specifiers in loadlib_aix.cpp
(P4) JDK-8234539: ArchiveRelocationTest.java failed: Archive mapping should always succeed
(P4) JDK-8233113: ARM32: assert on UnsafeJlong mutex rank check
(P4) JDK-8231457: Asserts on AIX because os::elapsed_counter() is not monotonic
(P4) JDK-8231257: Avoid calling FileMapInfo::write_region twice
(P4) JDK-8233494: Avoid calling MallocTracker::record_malloc and record_free when NMT is off
(P4) JDK-8227633: avoid comparing this pointers to NULL
(P4) JDK-8232071: Avoid shared dictionary lookup when the class name is not shared
(P4) JDK-8231895: Avoid String allocations in JVM_FindLoadedClass
(P4) JDK-8225344: Avoid VM_EnableBiasedLocking VM operation during bootstrap if BiasedLockingStartupDelay is 0
(P4) JDK-8237918: Bad copyright line in a hotspot test
(P4) JDK-8230876: baseline cleanups from Async Monitor Deflation v2.0[789]
(P4) JDK-8234127: BasicHashtable does not support small table_size
(P4) JDK-8233787: Break cycle in vm_version* includes
(P4) JDK-8214549: Bump maximum recognized class file version to 58 for JDK 14
(P4) JDK-8235499: Change HotSpot jtreg records test to better handle JDK updates
(P4) JDK-8235513: Change JVM to check for preview features using JVM_CLASSFILE_MAJOR_VERSION
(P4) JDK-8227766: CheckUnhandledOops is broken in MemAllocator
(P4) JDK-8233363: Clarify the DumpSharedSpaces condition in InstanceKlass::verify_on
(P4) JDK-8230401: ClassLoaderData::_keep_alive is read with wrong type in c2i entry barrier
(P4) JDK-8234748: Clean up atomic and orderAccess includes
(P4) JDK-8231472: Clean up Monitor::_safepoint_check usage to Mutex::_safepoint_check
(P4) JDK-8232980: Cleanup initialization of function pointers into java.base from classloader.cpp
(P4) JDK-8229212: clear up CHECK_OWNER confusion in objectMonitor.cpp
(P4) JDK-8230395: Code checks for NULL value returned from NEW_C_HEAP_ARRAY which can not happen
(P4) JDK-8230011: Consolidate duplicated classpath parsing code in classLoader.cpp
(P4) JDK-8232735: Convert PrintJNIResolving to Unified Logging
(P4) JDK-8230422: Convert uninterruptible os::sleep calls to os::naked_short_sleep
(P4) JDK-8229236: CriticalJNINatives: dll handling should be done in native thread state
(P4) JDK-8225788: Dead code in thread and safepoint
(P4) JDK-8184732: Deadlock detection improvements for 'special' locks
(P4) JDK-8230938: Deprecate MonitorBound
(P4) JDK-8234224: Document -XX:+ShowCodeDetailsInExceptionMessages in the java manpage
(P4) JDK-8235410: Enable handshakes on Linux x86 (32-bit)
(P4) JDK-8230586: Encapsulate fields in filemap.hpp
(P4) JDK-8234741: enhance os::get_core_path on macOS
(P4) JDK-8231844: Enhance type signature characters in classfile_constants.h and improve the JVM to use type signature characters more consistently
(P4) JDK-8227680: FastJNIAccessors: Check for JVMTI field access event requests at runtime
(P4) JDK-8234791: Fix Client VM build for x86_64 and AArch64
(P4) JDK-8229000: Fix lock and reenable assert in Monitor::check_safepoint_state
(P4) JDK-8227869: fix wrong format specifiers in os_aix.cpp
(P4) JDK-8228482: fix xlc16/xlclang comparison of distinct pointer types and string literal conversion warnings
(P4) JDK-8233530: gcc 5.4 build warning -Wc++14-compat after JDK-8233359
(P4) JDK-8235243: handle VS2017 15.9 and VS2019 in abstract_vm_version
(P4) JDK-8234563: Harmonize parameter order in Atomic
(P4) JDK-8234737: Harmonize parameter order in Atomic - add
(P4) JDK-8234740: Harmonize parameter order in Atomic - cmpxchg
(P4) JDK-8234736: Harmonize parameter order in Atomic - store
(P4) JDK-8234738: Harmonize parameter order in Atomic - sub
(P4) JDK-8234739: Harmonize parameter order in Atomic - xchg
(P4) JDK-8230708: Hotspot fails to build on linux-sparc with gcc-9
(P4) JDK-8231201: hs_err should print coalesced safepoint operations in Events section
(P4) JDK-8233446: Improve error handling when specified dynamic archive doesn't exist
(P4) JDK-8226238: Improve error output and fix elf issues in os::dll_load
(P4) JDK-8234656: Improve granularity of verifier logging
(P4) JDK-8234742: Improve handshake logging
(P4) JDK-8229027: Improve how JNIHandleBlock::oops_do distinguishes oops from non-oops
(P4) JDK-8232050: Improve inlining of Klass accessors
(P4) JDK-8231707: Improve Mutex inlining
(P4) JDK-8231125: Improve testing of parallel loading of shared classes by the boot class loader
(P4) JDK-8231024: Improve the debug info when the output is truncated
(P4) JDK-8233785: Incorrect JDK version is reported in hs_err log
(P4) JDK-8233386: Initialize NULL fields for unused decorations
(P4) JDK-8234735: InstanceKlass:find_method_index regression after JDK-8231610
(P4) JDK-8229930: internal_name() in annotations.hpp returns "{constant pool}"
(P4) JDK-8234613: JavaThread can escape back to Java from an ongoing handshake
(P4) JDK-8229808: javaVFrame::print_lock_info_on fails to disable extra printing
(P4) JDK-8223261: JDK-8189208 followup - remove JDK_GetVersionInfo0 and the supporting code
(P4) JDK-8220715: JEP 358: Helpful NullPointerExceptions
(P4) JDK-8230685: JNI FindClass should specify that the class is initialized
(P4) JDK-8233526: JVM support for records
(P4) JDK-8227035: JVM::printFlags fails in native OOM situations
(P4) JDK-8232616: JVMCI_lock fails to get initialized when cds is disabled
(P4) JDK-8230043: Lazily load libverify
(P4) JDK-8232207: Linux os::available_memory re-reads cgroup configuration on every invocation
(P4) JDK-8227527: LogDecorations should lazily resolve host name
(P4) JDK-8230003: Make Monitor inherit from Mutex
(P4) JDK-8226228: Make Threads_lock an always safepoint checked lock.
(P4) JDK-8227032: MetaspaceUtils::print_report crashes when called before initialization
(P4) JDK-8233159: Method::result_type should use calculated value in constMethod
(P4) JDK-8232151: Minimal VM build broken after JDK-8232050
(P4) JDK-8189633: Missing -Xcheck:jni checking for DeleteWeakGlobalRef
(P4) JDK-8226227: Missing include of thread.inline.hpp
(P4) JDK-8234512: Missing pieces from JDK-8224816
(P4) JDK-8232788: Move biased locking initialization
(P4) JDK-8214822: Move ConcurrentHashTable VALUE parameter to CONFIG
(P4) JDK-8232613: Move Object.registerNatives into HotSpot
(P4) JDK-8234562: Move OrderAccess::release_store*/load_acquire to Atomic
(P4) JDK-8230423: Move os::sleep to JavaThread::sleep
(P4) JDK-8233219: NMT output on AIX misses some categories
(P4) JDK-8227491: No documented method to specify initial caller frame from JNI
(P4) JDK-8234544: ObjectSynchronizer::FastHashCode() cleanups from Async Monitor Deflation project
(P4) JDK-8221205: Obsolete AllowJNIEnvProxy
(P4) JDK-8226304: Obsolete the -XX:+FailOverToOldVerifier option
(P4) JDK-8220049: Obsolete ThreadLocalHandshakes
(P4) JDK-8231751: on aix handle Power 9 in os::get_summary_cpu_info
(P4) JDK-8231630: Optimize boot loader with no bootclasspath append entry
(P4) JDK-8233497: Optimize default method generation by data structure reuse
(P4) JDK-8231094: os::sleep in assert message should be changed to JavaThread::sleep
(P4) JDK-8227031: Print NMT statistics on fatal errors
(P4) JDK-8234779: Provide idiom for declaring classes noncopyable
(P4) JDK-8234509: Race in macOS os::processor_id()
(P4) JDK-8229900: RedefineDeleteJmethod.java fails with -Xcheck:jni
(P4) JDK-8234796: Refactor Handshake::execute to take a more complex type than ThreadClosure
(P4) JDK-8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor
(P4) JDK-8228858: Reimplement JVM_RawMonitors to use PlatformMutex
(P4) JDK-8228630: Remove always true parameter to NoSafepointVerifier
(P4) JDK-8230563: Remove arguments_ext.cpp
(P4) JDK-8229844: Remove attempt_rebias parameter from revoke_and_rebias()
(P4) JDK-8232890: Remove bad Code attribute parsing code
(P4) JDK-8228400: Remove built-in AArch64 simulator
(P4) JDK-8234531: Remove CMS code from CLDG and safepoint cleanup
(P4) JDK-8232006: Remove dead code from klassVtable
(P4) JDK-8232211: Remove dead code from os.hpp|cpp
(P4) JDK-8227692: Remove develop feature PrintMallocStatistics
(P4) JDK-8228673: Remove develop flag StrictSafepointChecks
(P4) JDK-8224599: Remove globals_ext.hpp
(P4) JDK-8233913: Remove implicit conversion from Method* to methodHandle
(P4) JDK-8229836: Remove include of globals.hpp from allocation.hpp
(P4) JDK-8230561: Remove logTag_ext.hpp
(P4) JDK-8229208: Remove Monitor::ClearMonitor
(P4) JDK-8228484: Remove NoAllocVerifier because nothing uses it
(P4) JDK-8232147: Remove notproduct option IgnoreLockingAssertions
(P4) JDK-8231275: Remove null check in the beginning of SystemDictionary::load_shared_class()
(P4) JDK-8230564: Remove os_ext.hpp
(P4) JDK-8231993: Remove redundant pkg_str param from is_shared_class_visible_for_classloader
(P4) JDK-8231171: remove remaining sun.java.launcher.pid references
(P4) JDK-8227370: Remove SharedPathsMiscInfo
(P4) JDK-8232887: Remove SystemDictionary::has_checkPackageAccess
(P4) JDK-8235629: Remove unnecessary calls to Thread::current
(P4) JDK-8233266: Remove unnecessary fence in restore_unshareable_info
(P4) JDK-8232881: Remove unnecessary InstanceKlass::casts
(P4) JDK-8230140: Remove unused mutex and monitor declarations
(P4) JDK-8225628: Remove unused Thread::muxAcquireW function
(P4) JDK-8231278: Rename FileMapHeader::_read_only_tables_start to _serialized_data_start
(P4) JDK-8229838: Rename markOop files to markWord
(P4) JDK-8230877: Rename THREAD_LOCAL_DECL to THREAD_LOCAL
(P4) JDK-8230184: rename, whitespace, indent and comments changes in preparation for lock free Monitor lists
(P4) JDK-8230505: Replace JVM type comparisons to T_OBJECT and T_ARRAY with call to is_reference_type
(P4) JDK-8223400: Replace some enums with static const members in hotspot/runtime
(P4) JDK-8234304: runtime/cds/appcds/javaldr tests should use driver mode
(P4) JDK-8216977: ShowHiddenFrames use in java_lang_StackTraceElement::fill_in appears broken
(P4) JDK-8235359: Simplify method Class.getRecordComponents()
(P4) JDK-8233495: Some fieldDescriptor methods can pass existing constantPoolHandle
(P4) JDK-8235257: Split 'assert(loader != NULL && oopDesc::is_oop(loader), "loader must be oop")'
(P4) JDK-5103339: Strengthen NoSafepointVerifier
(P4) JDK-8232107: support ThreadPriorityPolicy flag on AIX
(P4) JDK-8227338: templateInterpreter.cpp: copy_table() needs to be safer
(P4) JDK-8233454: Test fails with assert(!is_init_completed(), "should only happen during init") after JDK-8229516
(P4) JDK-8231769: Test tools/javac/tree/MakeTypeTest.java fails with -Xcheck:jni
(P4) JDK-8225035: Thread stack size issue caused by large TLS size
(P4) JDK-8229516: Thread.isInterrupted() always returns false after thread termination
(P4) JDK-6313903: Thread.sleep(3) might wake up immediately on windows
(P4) JDK-8218543: ThreadsList handling during error reporting can crash
(P4) JDK-8230053: two docker tests failed due to SIGABRT
(P4) JDK-8227694: update link to JLS 14 in specs/jni/function.html
(P4) JDK-8230168: Use ClasspathStream for FileMapInfo::create_path_array
(P4) JDK-8224878: Use JVMFlag parameters instead of name strings
(P4) JDK-8231753: use more Posix functionality in aix os::print_os_info
(P4) JDK-8230424: Use platform independent code for Thread.interrupt support
(P4) JDK-8232052: use string literal for format string when handling PauseAtStartupFile
(P4) JDK-8227250: UserHandler contains ancient LinuxThreads code
(P4) JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN
(P4) JDK-8232757: VM fails to report an error for DumpLoadedClassList when cds is disabled
(P4) JDK-8234086: VM operation can be simplified
(P4) JDK-8231953: Wrong assumption in assertion in oop::register_oop
(P4) JDK-8234130: Zero VM build broken after JDK-8233913
(P5) JDK-8229967: Enable thread local handshakes on zero
hotspot/svc:
(P2) JDK-8227815: Minimal VM: set_state is not a member of AttachListener
(P3) JDK-8228554: Accessibility errors in jdwp-protocol.html
(P3) JDK-8230857: Avoid reflection in sun.tools.common.ProcessHelper
(P3) JDK-8235334: Deprecate jcmd GC.class_stats
(P3) JDK-8230611: infinite loop in LogOutputList::wait_until_no_readers()
(P3) JDK-8228448: Jconsole can't connect to itself
(P4) JDK-8227124: "could not open pipe" error does not report error details
(P4) JDK-8228649: [PPC64] SA reads wrong slots from interpreter frames
(P4) JDK-8235403: Further cleanup to test serviceability/sa/ClhsdbCDSCore.java
(P4) JDK-8229957: Harden pid verification in attach mechanism
(P4) JDK-8234625: hs test serviceability/sa/ClhsdbCDSCore.java fails on macOS 10.15
(P4) JDK-8225690: Multiple AttachListener threads can be created
(P4) JDK-8231981: Refactor test definitions to split RT and SVC tests
(P4) JDK-8231768: Remove duplicate if/else in vmTestbase/nsk/share/jdi/Binder.java
(P4) JDK-8235530: Removed duplicated threadByName methods in nsk/jdi tests
hotspot/svc-agent:
(P2) JDK-8225801: Shenandoah: Adjust SA to reflect recent forwarding pointer changes
(P3) JDK-8236062: Disable clhsdb initialization of SA javascript support since it will always fail, and will likely be removed soon
(P3) JDK-8235637: jhsdb jmap from OpenJDK 11.0.5 doesn't work if prelink is enabled
(P3) JDK-8196969: JTreg Failure: serviceability/sa/ClhsdbJstack.java causes NPE
(P3) JDK-8231635: SA Stackwalking code stuck in BasicTypeDataBase.findDynamicTypeForAddress()
(P3) JDK-8209790: SA tools not providing option to connect to debug server
(P3) JDK-8230881: serviceability/sa/TestJmapCore tests fail with java.lang.RuntimeException: Could not find dump file
(P3) JDK-8227645: Some tests in serviceability/sa run with fixed -Xmx values and risk running out of memory
(P4) JDK-8231287: "jhsdb jmap" should do a better job of reporting exception it catches
(P4) JDK-8231288: "jhsdb jmap" test needed to reproduce issues that used to be reproduced by JShellHeapDumpTest
(P4) JDK-8232592: is shown in jstack mixed mode
(P4) JDK-8230466: check malloc/calloc results in jdk.hotspot.agent
(P4) JDK-8231986: Consolidate parts of the Linux and MacOSX versions of ps_core.c
(P4) JDK-8233285: Demangling C++ symbols in jhsdb jstack --mixed
(P4) JDK-8230666: Exclude serviceability/sa/TestInstanceKlassSize.java on linuxppc64 and linuxppc64le
(P4) JDK-8232973: Potential infinite loop in macOS hotspot agent
(P4) JDK-8225636: SA can't handle prelinked libraries
(P4) JDK-8216352: SA: ClhsdbLauncher should throw errors on Unrecognized commands
(P4) JDK-8226204: SA: Refactoring for option processing in SALauncher
(P4) JDK-8225804: SA: Remove unused CollectedHeap.oopOffset() method
(P4) JDK-8230942: Support compressed cores in SA tests
hotspot/test:
(P4) JDK-8230854: Cleanup SuppressWarnings in test lib and remove noisy traces in StreamPumper
(P4) JDK-8226282: Kitchensink: Implement class loading/unloading of SpecJbb005
(P4) JDK-8231035: runThese24H times out
infrastructure:
(P2) JDK-8223671: The latest Java 8 is not ready to use in applications on future macOS versions
(P3) JDK-8234964: failure_handler: gather more environment information on Windows, Solaris and Linux
(P3) JDK-8232880: Update test documentation with additional settings for client UI tooltip tests
(P4) JDK-8235866: bump jtreg requiredVersion to 4.2b16
(P4) JDK-8227171: provide function names in native stack trace on aix with xlc16
(P4) JDK-8227247: tools/sjavac/IdleShutdown.java fails with AssertionError: Error too big on windows
infrastructure/build:
(P2) JDK-8235814: Add --enable-deprecated-ports=yes to all solaris and SPARC build profiles
(P2) JDK-8235686: Add more custom hooks in Bundles.gmk
(P2) JDK-8231974: Build fails if no common legal notices are present
(P2) JDK-8231505: Bump required boot jdk version to 13
(P2) JDK-8232133: Change to GCC 8.3 for building on Linux at Oracle
(P2) JDK-8232134: Change to Visual Studio 2017 15.9.16 for building on Windows at Oracle
(P2) JDK-8235687: Contents/MacOS/libjli.dylib cannot be a symlink
(P2) JDK-7044739: Provide legal notice check.
(P2) JDK-8015626: Update jcheck to verify the syntax of the Oracle copyright line, to prevent checking in of typos in said line.
(P3) JDK-8230715: Baseline compare build on Windows fails intermittently in file type for jvm.pdb
(P3) JDK-8231902: Build of jdk.internal.vm.compiler.management/module-info.java.extra failed
(P3) JDK-8232748: Build static versions of certain JDK libraries
(P3) JDK-8233600: cross-builds fails after JDK-8233285
(P3) JDK-8234525: enable link-time section-gc for linux s390x to remove unused code
(P3) JDK-8235585: Enable macOS codesigning for all libraries and executables
(P3) JDK-8232770: Enable more warnings on solaris studio
(P3) JDK-8233112: Exclude SVG files from build comparison
(P3) JDK-8231467: Missing make prerequisite declaration corrupts make dependency files on Windows
(P3) JDK-8211073: Remove -Wno-extra from Hotspot
(P3) JDK-8232834: RunTest sometimes fails to produce valid exitcode.txt
(P3) JDK-8234809: set relro in linker flags when building with gcc
(P3) JDK-8233880: Support compilers with multi-digit major version numbers
(P3) JDK-8226359: Switch to JCov build which supports byte code version 58
(P3) JDK-8216354: Syntax error in toolchain_windows.m4
(P3) JDK-8228426: xlc: switch to clang-style warning disabling
(P4) JDK-8227170: (.hg)Ignore the JTwork and JTreport directories generated at the root of the repo
(P4) JDK-8224214: [AIX] Remove support for legacy xlc compiler
(P4) JDK-8206125: [windows] cannot pass relative path to --with-boot-jdk
(P4) JDK-8235789: AC_REQUIRE: `PLATFORM_EXTRACT_TARGET_AND_BUILD' was expanded before it was required
(P4) JDK-8227397: Add --with-extra-asflags configure option
(P4) JDK-6903627: Add GPL license checker code tool
(P4) JDK-8230485: add handling of aix tar in configure
(P4) JDK-8232572: Add hooks for custom output dir in Bundles.gmk
(P4) JDK-8230781: Add JTREG_FAILURE_HANDLER_TIMEOUT to control timeout handler timeout
(P4) JDK-8231351: Add notes for PKCS11 tests in the test doc
(P4) JDK-8230067: Add optional automatic retry when running jtreg tests
(P4) JDK-8227834: build.log output from failing commands : include the hs_error file path in case of crashes in build
(P4) JDK-8229981: Change ® to be superscript
(P4) JDK-8232639: Change module graph images to use SVG instead of PNG format.
(P4) JDK-8232768: Configuration with --disable-cds --enable-generate-classlist should be reported as an error
(P4) JDK-8213239: Configure cannot handle command overrides with arguments
(P4) JDK-8072223: Create license checker for the JDK sources
(P4) JDK-8234535: Cross compilation fails due to missing CFLAGS for the BUILD_CC
(P4) JDK-8226521: Detect WSL2 as WSL in configure
(P4) JDK-8234370: Implementation of JEP 362: Deprecate the Solaris and SPARC Ports
(P4) JDK-7178798: Improvements for the JDK source code legal headers verification process.
(P4) JDK-8210794: Incorrect escaping of $ORIGIN in native test libraries
(P4) JDK-8233712: Limit default tests jobs based on ulimit -u setting
(P4) JDK-8150741: make not equivalent to make
(P4) JDK-8223998: Missing MakeDir in ExecuteWithLog
(P4) JDK-8058539: Platform specific source files may not end up in src.zip
(P4) JDK-8227389: Remove unsupported xlc16 compile options on aix
(P4) JDK-8065704: Set LC_ALL=C for all relevant commands in the build system
(P4) JDK-8227652: SetupOperatorNewDeleteCheck should discuss deleting destructors
(P4) JDK-8226325: Support building of filtered spec bundles
(P4) JDK-8235959: Update --release 14 symbol information up to JDK 14 b31
(P4) JDK-8233381: Update copyright year in build system files
(P4) JDK-8230079: Update test document by changing "TIMEOUT" to "TIMEOUT_FACTOR"
(P4) JDK-8031136: update_copyright_year.sh can be smarter to exclude changesets only to previous copyright updates.
(P4) JDK-8234835: Use UTF-8 charset in fixuppandoc
(P4) JDK-8233383: Various minor fixes
(P4) JDK-8232167: Visual Studio install found through --with-tools-dir value is discarded
other-libs/other:
(P4) JDK-8232234: Suppress warnings on non-serializable non-transient instance fields in java.rmi
performance/libraries:
(P2) JDK-8215521: add microbenchmark to measure AccessController.getContext
security-libs:
(P4) JDK-8233884: Avoid looking up standard charsets in security libraries
(P4) JDK-8229214: Don't use GCM with PKCS5Padding in test/micro/org/openjdk/bench/javax/crypto/
(P4) JDK-8230407: SocketPermission and FilePermission action list allows leading comma
(P4) JDK-8233404: System property to set the number of PBE iterations in JCEKS keystores
security-libs/java.security:
(P2) JDK-8228969: 2019-09-28 public suffix list update
(P2) JDK-8236098: AlgorithmConstraints:permits method not throwing IAEx when primitives are empty
(P2) JDK-8233228: Disable weak named curves by default in TLS, CertPath, and Signed JAR
(P2) JDK-8234245: sun/security/lib/cacerts/VerifyCACerts.java fails due to wrong checksum
(P3) JDK-8233223: Add Amazon Root CA certificates
(P3) JDK-8232019: Add LuxTrust certificate updates to the existing root program
(P3) JDK-8236470: Deal with ECDSA using ecdsa-with-SHA2 plus hash algorithm as AlgorithmId
(P3) JDK-8228578: fix CFData object leak in macosx KeystoreImpl.m
(P3) JDK-8236145: Incorrect spec on ECDSA P1363 signature format
(P3) JDK-8228613: java.security.Provider#getServices order is no longer deterministic
(P3) JDK-8231387: java.security.Provider.getService returns random result due to race condition with mutating methods in the same class
(P3) JDK-8234744: KeyStore.store can write wrong type of file
(P3) JDK-8214483: Remove algorithms that use MD5 or DES from security requirements
(P3) JDK-8191138: Remove deprecated java.security.acl APIs
(P3) JDK-8214024: Remove the default keytool -keyalg value
(P3) JDK-8229773: Resolve permissions for code source URLs lazily
(P3) JDK-8228745: sun/security/tools/jarsigner/Warning.java test timeout
(P3) JDK-8231887: Test security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java fails because certificate was revoked
(P4) JDK-8229999: Apply java.io.Serial annotations to security types in java.base
(P4) JDK-8230415: Avoid redundant permission checking in FilePermissionCollection and SocketPermissionCollection
(P4) JDK-8226307: Curve names should be case-insensitive
(P4) JDK-8231950: keytool -ext camel-case shorthand not working
(P4) JDK-8230861: missing ReleaseStringUTFChars in Java_sun_security_pkcs11_wrapper_PKCS11_connect
(P4) JDK-8234377: new BitArray(0).toString() throws ArrayIndexOutOfBoundsException
(P4) JDK-8236957: Obvious typo in java/security/spec/RSAMultiPrimePrivateCrtKeySpec.java
(P4) JDK-8235183: Remove the "HACK CODE" in comment
(P4) JDK-8225436: Stapled OCSPResponses should be added to PKIXRevocationChecker irrespective of revocationEnabled flag
(P4) JDK-8231262: Suppress warnings on non-serializable instance fields in security libs serializable classes
(P4) JDK-8234273: Update keytool documentation on the removal of default -keyalg values
security-libs/javax.crypto:
(P2) JDK-8233954: UnsatisfiedLinkError or NoSuchAlgorithmException after removing sunec.dll
(P3) JDK-8210755: Define standard names for EC curves and TLS signature schemes
(P3) JDK-8234924: Deprecate the legacy elliptic curves for removal
(P3) JDK-8234870: Deprecate the OracleUcrypto JCE Provider for removal
(P3) JDK-8231598: keytool does not export sun.security.mscapi
(P3) JDK-8233016: Specify the exceptions that can be thrown by the javax.crypto.Cipher constructor
(P4) JDK-8228668: compiler/codegen/aes/TestAESMain.java failed with GCM mode must be used with NoPadding
(P4) JDK-8226543: Reduce GC pressure during message digest calculations in password-based encryption
(P4) JDK-8180392: SunJCE provider should throw exceptions for unsupported mode and padding combinations
security-libs/javax.crypto:pkcs11:
(P3) JDK-8228835: Memory leak in PKCS11 provider when using AES GCM
(P3) JDK-8232950: SUNPKCS11 Provider incorrectly check key length for PSS Signatures.
(P3) JDK-8180837: SunPKCS11-NSS tests failing with CKR_ATTRIBUTE_READ_ONLY and CKR_MECHANISM_PARAM_INVALID
(P3) JDK-8229243: SunPKCS11-Solaris provider tests failing on Solaris 11.4
(P3) JDK-8226221: Update PKCS11 tests to use NSS 3.46 libs
(P4) JDK-8228645: Don't run sun/security/pkcs11/Cipher/TestKATForGCM.java on buggy NSS solaris versions
(P4) JDK-8231222: fix pkcs11 P11_DEBUG guarded native traces
(P4) JDK-8236897: Fix the copyright header for pkcs11gcm2.h
(P4) JDK-8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14
(P4) JDK-8176837: SunPKCS11 provider needs to check more details on PKCS11 Mechanism
security-libs/javax.net.ssl:
(P2) JDK-8223940: Private key not supported by chosen signature algorithm
(P3) JDK-8224997: ChaCha20-Poly1305 TLS cipher suite decryption throws ShortBufferException
(P3) JDK-8228757: Fail fast if the handshake type is unknown
(P3) JDK-8231810: javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java fails intermittently with "java.lang.Exception: Unexpected EOF"
(P3) JDK-8233621: Mismatch in jsse.enableMFLNExtension property name
(P3) JDK-8190492: Remove SSLv2Hello and SSLv3 from default enabled TLS protocols
(P3) JDK-8226374: Restrict TLS signature schemes and named groups
(P3) JDK-8235263: Revert TLS 1.3 change that wrapped IOExceptions
(P3) JDK-8235874: The ordering of Cipher Suites is not maintained provided through “jdk.tls.client.cipherSuites” and “jdk.tls.server.cipherSuites” system property.
(P4) JDK-8133489: Better messaging for PKIX path validation matching
(P4) JDK-8235655: Clean the duplicated block in SSLContextImpl
(P4) JDK-8235448: code cleanup in SSLContextImpl.java
(P4) JDK-8234724: javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java supports TLSv1.3
(P4) JDK-8234723: javax/net/ssl/TLS tests support TLSv1.3
(P4) JDK-8228396: Re-enable Stateless Resumption On by default for merge to mainline
(P4) JDK-8234728: Some security tests should support TLSv1.3
(P4) JDK-8234725: sun/security/ssl/SSLContextImpl tests support TLSv1.3
(P4) JDK-8234727: sun/security/ssl/X509TrustManagerImpl tests support TLSv1.3
(P4) JDK-8235813: System property fullCipherSuites is not used by javax/net/ssl/compatibility/Compatibility.java
(P4) JDK-8235311: Tag mismatch may alert bad_record_mac
(P4) JDK-8228967: Trust/Key store and SSL context utilities for tests
security-libs/javax.security:
(P2) JDK-8234267: DelegationPermission implementation doesn't completely follow the updated specification
(P3) JDK-8233222: Clarify system property usage in KerberosPrincipal instantiation
(P3) JDK-8231196: DelegationPermission allows to create an instance that thows NPE on ::equals call
(P3) JDK-8231365: ServicePermission::equals doesn't comply to the spec
(P4) JDK-8229767: Typo in java.security: Sasl.createClient and Sasl.createServer
security-libs/javax.xml.crypto:
(P3) JDK-8231507: Update Apache Santuario (XML Signature) to version 2.1.4
(P4) JDK-8232357: Compare version info of Santuario to legal notice
security-libs/jdk.security:
(P4) JDK-8229775: Incorrect warning when jar was signed with -sectionsonly
(P4) JDK-8230910: libsspi_bridge does not build on Windows 32bit
security-libs/org.ietf.jgss:
(P4) JDK-8228659: Record which Java methods are called by native codes in JGSS and JAAS
(P4) JDK-8231368: Suppress warnings on non-serializable non-transient instance fields in java.security.jgss
security-libs/org.ietf.jgss:krb5:
(P4) JDK-8233946: Add @since 13 annotation to KerberosPrincipal.KRB_NT_ENTERPRISE field
specification/language:
(P2) JDK-8230539: JEP 361: Switch Expressions
(P3) JDK-8181287: JEP 305: Pattern Matching for instanceof (Preview)
(P3) JDK-8222777: JEP 359: Records (Preview)
(P3) JDK-8231623: JEP 368: Text Blocks (Second Preview)
(P3) JDK-8236679: Records: Local records shouldn't capture any non-static state from any enclosing type
(P4) JDK-8231433: 1.5: Robust handling of code using essential APIs associated with preview features
(P4) JDK-8231435: 9.6.4.1: Expand no-@Target to mean "applicable in all contexts"
(P4) JDK-8231147: 9.6.4.5: Clarify that @SuppressWarnings requires unknown strings to be ignored
(P4) JDK-8235617: JLS changes for Pattern Matching for instanceof (Preview)
(P4) JDK-8225057: JLS changes for Records (Preview)
(P4) JDK-8235616: JLS changes for Text Blocks (Second Preview)
(P5) JDK-8232632: 3.10.4: Explicitly mention that character literals can't contain \u0027 (') characters
specification/vm:
(P4) JDK-8236509: 4.1: Allow v58.0 class files for Java SE 14
(P4) JDK-8225058: JVMS changes for Records (Preview)
tools:
(P3) JDK-8235767: Compilation failure caused by JDK-8212780: Packaging Tool Implementation
(P3) JDK-8225773: jdeps --check produces NPE if there is any missing module dependence
(P3) JDK-8229396: jdeps ignores multi-release when generate-module-info used on command line
(P3) JDK-8237185: Remove Pack200 spec and references from documentation
(P4) JDK-8232170: FSInfo#getJarClassPath throws an exception not declared in its throws clause
(P4) JDK-8230162: ScopeImpl.remove() has O(N) performance
tools/jar:
(P3) JDK-8232022: JEP 367: Remove the Pack200 Tools and API
(P3) JDK-8234542: Remove Pack200 Tools and API
tools/javac:
(P1) JDK-8235778: No compilation error reported when a record is declared in a local class
(P2) JDK-8232681: ArrayIndexOutOfBoundsException with text blocks in javac when using -Xlint
(P2) JDK-8234101: Compilation error thrown when repeating annotation is used on record component
(P2) JDK-8234899: Compiler reports AssertionError for conditional operator ? : and pattern matching for instanceof
(P2) JDK-8236670: Conflicting bindings accepted in some cases
(P2) JDK-8235457: Crash when reporting a message about an annotation on a module
(P2) JDK-8232684: Make switch expressions final
(P2) JDK-8234922: No compilation error reported not reported for a binding variable when loop broken with label
(P2) JDK-8233655: NPE at jdk.compiler/com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitApply
(P2) JDK-8231176: Test tools/javac/options/BCPOrSystemNotSpecified.java broken on Windows
(P3) JDK-8231443: Add java.io.Serial to list of platform annotations for annotation processing
(P3) JDK-8234211: allow discoverable javac plugins to be invoked by default
(P3) JDK-8223443: Calling Trees.getScope early changes names of local/anonymous classes
(P3) JDK-8236266: change error message for the case when a class extends j.l.Record
(P3) JDK-8234687: change javap reporting on unknown attributes
(P3) JDK-8236841: compact constructor parameters are always final
(P3) JDK-8225054: Compiler implementation for records
(P3) JDK-8235446: confusing error message for records with no parens
(P3) JDK-8236544: confusing error message: return type of accessor method is not compatible with type of record component
(P3) JDK-8234025: Elements.getPackageElement(ModuleElement,CharSequence) returns null for unnamed package
(P3) JDK-8234689: facilitate writing additional custom attributes in a class file
(P3) JDK-8231826: Implement javac changes for pattern matching for instanceof
(P3) JDK-8226585: Improve javac messages for using a preview API
(P3) JDK-8177068: incomplete classpath causes NPE in Flow
(P3) JDK-8228502: javac crashed on a broken classfile with ConstantValue attribute on a field of type Object
(P3) JDK-8218268: Javac treats Manifest Class-Path entries as Paths instead of URLs
(P3) JDK-8233680: JavacFileManager.close() doesn't clear some cache instance variables
(P3) JDK-8236005: local records shouldn't capture any non-static state from any enclosing type
(P3) JDK-8235458: Problem caused by imports in a module-info.java file
(P3) JDK-8214916: SourceLauncherTest fails on exploded image
(P3) JDK-8234445: spurious error message for record constructors with receiver parameters
(P3) JDK-8236692: static final fields without initializer are accepted by javac
(P3) JDK-8235338: test jdk/jshell/CompletenessTest.java fails for records
(P3) JDK-8230847: Trees.getScope may crash when invoked for statement inside switch.
(P3) JDK-8225761: Update --release 13 symbol information after JDK 13 GA
(P3) JDK-8236546: Yield with boolean expression and Object target type crashes javac.
(P4) JDK-8230105: -XDfind=diamond crashes
(P4) JDK-8214548: Add source 14 and target 14 to javac
(P4) JDK-8228460: bootstrap class path not set in conjunction with -source 11
(P4) JDK-8228647: Broken enum produce inconvenient errors and AST
(P4) JDK-8226314: com.sun.source support for records
(P4) JDK-8227922: DocTreeScanner does not dive into AttributeTree.getValue() and LiteralTree.getBody()
(P4) JDK-8227923: End position of EndElementTree is -1
(P4) JDK-8227010: Error recovery after local variable redeclaration can be improved
(P4) JDK-8235597: Extend support for -XDaccessInternalAPI to plugin modules
(P4) JDK-8234729: Javac should eagerly change code generation for method references to avert IllegalAccessError in future.
(P4) JDK-8164819: Make javac's toString() on annotation objects consistent with core reflection
(P4) JDK-8226785: MandatoryWarningHandler.java contains implementation of Object.equals functionality
(P4) JDK-8231414: Mark various instance fields of javac internal types as transient
(P4) JDK-8234078: Missing license headers in a few javac files
(P4) JDK-8231990: Remove unnecessary else-if branch in Types.union
(P4) JDK-8235621: Replace use of Function with ToIntFunction
(P4) JDK-8235483: Warnings printed during the build
(P4) JDK-8233524: Wrong module name for "package P is declared in the unnamed module, but module M does not read it"
(P5) JDK-8229386: Typo "lables" in doc comment
tools/javadoc(tool):
(P3) JDK-8231122: @index tag with newline causes tag search to fail
(P3) JDK-8215038: Add a page that lists all system properties
(P3) JDK-8223378: CSS solution for navbar problem with elements is not ideal
(P3) JDK-8234746: Improve indexing of system properties
(P3) JDK-8227696: Improve text in Doc Comment Spec for HTML content
(P3) JDK-8227697: Improve text in Taglet API spec for expected results with standard doclet
(P3) JDK-8224052: Javadoc doesn't handle non-public intermediate types well
(P3) JDK-8220217: Javadoc missing link to member method
(P3) JDK-8235670: Javadoc pages not printing correctly in some browsers
(P3) JDK-8231587: Memory leak in WorkArounds.serializedForms
(P3) JDK-8222791: Order of evaluation of -link params in Javadoc tool reversed -> regression with split packages
(P3) JDK-8223252: Update Javadoc help page with new search features
(P4) JDK-8228393: Add an indicator for external links in javadoc
(P4) JDK-8225055: Javadoc for records
(P4) JDK-8235414: Module level doc-files show "unnamed package" as holder
(P4) JDK-8235435: Remove (obsolete) @author info from javadoc source and tests
(P4) JDK-8225802: Remove unused CSS classes from HTML doclet
(P4) JDK-8233866: Text in table cells has inconsistent alignment
tools/javap:
(P3) JDK-8225748: Use SHA-256 for javap classfile checksum
tools/jextract:
(P3) JDK-8237370: Javadoc of memory access API still refers to old MemoryAddress::offset method
tools/jlink:
(P3) JDK-8232080: jlink plugins for vendor information and command-line options
(P3) JDK-8222100: tools/jimage/JImageTest.java time out
(P3) JDK-8222098: tools/jlink/plugins/IncludeLocalesPluginTest.java time out
(P3) JDK-8234696: tools/jlink/plugins/VendorInfoPluginsTest.java times out
(P4) JDK-8232864: Classes generated at link time by GenerateJLIClassesPlugin are not reproducible
(P4) JDK-8225561: jlink --help doesn't state that ALL-MODULE-PATH is accepted for --add-modules
(P4) JDK-8225562: jlink --module-path behavior inconsistent with help/errors
(P4) JDK-8220700: jlink generated launcher script needs quoting to avoid parameter expansion
tools/jpackage:
(P2) JDK-8237607: [macos] Signing app bundle with jpackage fails if runtime is already signed
(P2) JDK-8235738: [macos] tools/jpackage tests timeout on macOS
(P2) JDK-8235728: JDK-8212780 breaks builds with a custom X11 include path
(P2) JDK-8235264: man pages for jpackage
(P2) JDK-8212780: Packaging Tool Implementation
(P2) JDK-8238168: Remove Copyright from WinLauncher.template
(P3) JDK-8234284: [dmg] Change DMG background image to TIFF
(P3) JDK-8235750: [jpackage] Cleanup imports in WinMsiBundler.java
(P3) JDK-8200758: JEP 343: Packaging Tool (Incubator)
(P3) JDK-8235453: tools/jpackage/junit/junit.java failed due to "module not found: jdk.incubator.jpackage"
(P3) JDK-8236125: Windows (MSVC 2013) build fails in jpackage: Need to include strsafe.h after tchar.h
(P4) JDK-8234867: Issue warning for mutually exclusive options on jpackage command line
(P4) JDK-8235601: redundant code in IOUtils.java
tools/jshell:
(P2) JDK-8210527: JShell: NullPointerException in jdk.jshell.Eval.translateExceptionStack
(P3) JDK-8226848: jline/terminal/impl files missing classpath exception clause in license header
(P3) JDK-8235474: JShell does not handle records properly
(P3) JDK-8236715: JShell: Records with errors are not properly corraled
(P4) JDK-8237916: Bad copyright line in a jshell source file
(P4) JDK-8212167: JShell : Stack trace of exception has wrong line number
(P4) JDK-8232855: jshell missing word in /help help
(P4) JDK-8231545: Suppress warnings on non-serializable instance fields in jdk.jshell module
(P4) JDK-8229815: Upgrade Jline to 3.12.1
(P5) JDK-8159740: JShell: corralled declarations do not have correct source to wrapper mapping
tools/launcher:
(P2) JDK-8231863: Crash if classpath is read from @argument file and the main gets option argument
(P2) JDK-8234076: JVM crashes on Windows 10 using --module=NAME
(P4) JDK-8234821: remove unused functions from libjli
(P4) JDK-8234339: replace JLI_StrTok in java_md_solinux.c
xml/javax.xml.parsers:
(P3) JDK-8016914: CoreDocumentImpl.setXmlVersion NPE
xml/javax.xml.stream:
(P3) JDK-8230094: CCE in createXMLEventWriter(Result) over an arbitrary XMLStreamWriter
(P4) JDK-7148925: StAXSource causes exceptions to be thrown with certain wellformed XML instances
xml/javax.xml.transform:
(P3) JDK-8223291: Whitespace is added to CDATA tags when using OutputKeys.INDENT to format XML
(P4) JDK-8178843: A bug in an inner loop in MethodGenerator's getLocals method
(P4) JDK-8228854: Default ErrorListener reports warnings and errors to the console
(P4) JDK-8157830: Errors in XSLT stylesheet are not dispatched correctly to ErrorListener
(P4) JDK-8233686: XML transformer uses excessive amount of memory
xml/javax.xml.validation:
(P4) JDK-8068376: Validator fails valid XML files due to String == in XSD validator code
xml/jaxp:
(P4) JDK-8224157: BCEL: update to version 6.3.1
(P4) JDK-8230814: Enable SAX ContentHandler to handle XML Declaration
(P4) JDK-8230002: javax/xml/jaxp/unittest/transform/SecureProcessingTest.java runs zero test
(P4) JDK-8230010: Remove jdk8037819/BasicTest1.java
(P4) JDK-8232713: Update BCEL version to 6.3.1 in license file
(P4) JDK-8233548: Update CUP to v0.11b
xml/org.xml.sax:
(P4) JDK-8231083: Clarify SAX documentation
(P4) JDK-8229388: ErrorHandler and ContentHandler contain ambiguous/unfinished specification
(P4) JDK-8176447: javax.xml.validation.Validator validates incorrectly on uniqueness constraint