RELEASE NOTES FOR: 11 ==================================================================================================== Notes generated: Fri Jul 01 04:11:43 CEST 2022 Hint: Prefix bug IDs with https://bugs.openjdk.java.net/browse/ to reach the relevant JIRA entry. JAVA ENHANCEMENT PROPOSALS (JEP): JEP 181: Nest-Based Access Control Introduce _nests_, an access-control context that aligns with the existing notion of nested types in the Java programming language. Nests allow classes that are logically part of the same code entity, but which are compiled to distinct class files, to access each other's private members without the need for compilers to insert accessibility-broadening bridge methods. JEP 309: Dynamic Class-File Constants Extend the Java class-file format to support a new constant-pool form, `CONSTANT_Dynamic`. Loading a `CONSTANT_Dynamic` will delegate creation to a bootstrap method, just as linking an `invokedynamic` call site delegates linkage to a bootstrap method. JEP 315: Improve Aarch64 Intrinsics Improve the existing string and array intrinsics, and implement new intrinsics for the `java.lang.Math` sin, cos and log functions, on AArch64 processors. JEP 318: Epsilon: A No-Op Garbage Collector (Experimental) Develop a GC that handles memory allocation but does not implement any actual memory reclamation mechanism. Once the available Java heap is exhausted, the JVM will shut down. JEP 320: Remove the Java EE and CORBA Modules Remove the Java EE and CORBA modules from the Java SE Platform and the JDK. These modules were [deprecated in Java SE 9](http://cr.openjdk.java.net/~iris/se/9/java-se-9-fr-spec/#APIs-proposed-for-removal) with the declared intent to remove them in a future release. JEP 321: HTTP Client Standardize the [incubated][JEP 11] HTTP Client API introduced in JDK 9, via [JEP 110][JEP 110], and updated in JDK 10. JEP 323: Local-Variable Syntax for Lambda Parameters Allow `var` to be used when declaring the formal parameters of implicitly typed lambda expressions. JEP 324: Key Agreement with Curve25519 and Curve448 Implement key agreement using Curve25519 and Curve448 as described in [RFC 7748](https://tools.ietf.org/html/rfc7748). JEP 327: Unicode 10 Upgrade existing platform APIs to support [version 10.0][1] of the [Unicode Standard][2]. JEP 328: Flight Recorder Provide a low-overhead data collection framework for troubleshooting Java applications and the HotSpot JVM. JEP 329: ChaCha20 and Poly1305 Cryptographic Algorithms Implement the ChaCha20 and ChaCha20-Poly1305 ciphers as specified in [RFC 7539][rfc7539]. ChaCha20 is a relatively new stream cipher that can replace the older, insecure RC4 stream cipher. JEP 330: Launch Single-File Source-Code Programs Enhance the `java` launcher to run a program supplied as a single file of Java source code, including usage from within a script by means of ["shebang" files](#Shebang_files) and related techniques. JEP 331: Low-Overhead Heap Profiling Provide a low-overhead way of sampling Java heap allocations, accessible via JVMTI. JEP 332: Transport Layer Security (TLS) 1.3 Implement version 1.3 of the Transport Layer Security (TLS) Protocol [RFC 8446]. JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental) The Z Garbage Collector, also known as ZGC, is a scalable low-latency garbage collector. JEP 335: Deprecate the Nashorn JavaScript Engine Deprecate the Nashorn JavaScript script engine and APIs, and the `jjs` tool, with the intent to remove them in a future release. JEP 336: Deprecate the Pack200 Tools and API Deprecate the `pack200` and `unpack200` tools, and the `Pack200` API in `java.util.jar`. RELEASE NOTES, BY COMPONENT: tools/javac: JDK-8207180: --add-exports No Longer Implies Readability in javac Running `javac` with the `--add-exports` command line option will no longer automatically make the exporting module readable by the target module. If needed, use the `--add-reads` option to let the target module read the exporting module. JDK-8210679: JEP 330: Launch Single-File Source-Code Programs Enhance the java launcher to run a program supplied as a single file of Java source code, including usage from within a script by means of "shebang" files and related techniques. JDK-8204542: Packages Not Visible in Imports Are Rejected `javac` used to accept imports from packages that were not visible in the current module but whose names were prefixes of names of visible packages. These are now rejected when compiling with -source >= 9. JDK-8207180: --add-exports No Longer Implies Readability in javac Running `javac` with the `--add-exports` command line option will no longer automatically make the exporting module readable by the target module. If needed, use the `--add-reads` option to let the target module read the exporting module. JDK-8210679: JEP 330: Launch Single-File Source-Code Programs Enhance the java launcher to run a program supplied as a single file of Java source code, including usage from within a script by means of "shebang" files and related techniques. JDK-8204542: Packages Not Visible in Imports Are Rejected `javac` used to accept imports from packages that were not visible in the current module but whose names were prefixes of names of visible packages. These are now rejected when compiling with -source >= 9. JDK-8207180: --add-exports No Longer Implies Readability in javac Running `javac` with the `--add-exports` command line option will no longer automatically make the exporting module readable by the target module. If needed, use the `--add-reads` option to let the target module read the exporting module. JDK-8210679: JEP 330: Launch Single-File Source-Code Programs Enhance the java launcher to run a program supplied as a single file of Java source code, including usage from within a script by means of "shebang" files and related techniques. JDK-8204542: Packages Not Visible in Imports Are Rejected `javac` used to accept imports from packages that were not visible in the current module but whose names were prefixes of names of visible packages. These are now rejected when compiling with -source >= 9. core-libs/java.net: JDK-8209634: JEP 321: HTTP Client (Standard) Standardize the incubated HTTP Client API introduced in JDK 9, via JEP 110, and updated in JDK 10 ([JEP 321](http://openjdk.java.net/jeps/321)). The HTTP Client has been standarized in Java 11. As part of this work the previously incubating API, located in the ` jdk.incubator.http` package, has been removed. At a very minimum, code that uses types from the `jdk.incubator.http` package will need to be updated to import the HTTP types from the standard package name, `java.net.http.` JDK-8198956: URLClassLoader Does Not Specify Behavior When URL Array Contains null URLClassLoader's constructors are specified to throw a NullPointerException if the URL array includes a null element. JDK-8209634: JEP 321: HTTP Client (Standard) Standardize the incubated HTTP Client API introduced in JDK 9, via JEP 110, and updated in JDK 10 ([JEP 321](http://openjdk.java.net/jeps/321)). The HTTP Client has been standarized in Java 11. As part of this work the previously incubating API, located in the ` jdk.incubator.http` package, has been removed. At a very minimum, code that uses types from the `jdk.incubator.http` package will need to be updated to import the HTTP types from the standard package name, `java.net.http.` JDK-8198956: URLClassLoader Does Not Specify Behavior When URL Array Contains null URLClassLoader's constructors are specified to throw a NullPointerException if the URL array includes a null element. hotspot/jvmti: JDK-8210680: JEP 331: Low-Overhead Heap Profiling Provide a low-overhead way of sampling Java heap allocations, accessible via JVMTI ([JEP 331](http://openjdk.java.net/jeps/331)). It is designed to meet the following goals: - Low-overhead enough to be continuously enabled by default - Accessible via a well-defined, programmatic interface (JVMTI) - Can sample all allocations (that is, not limited to allocations that are in one particular heap region or that were allocated in one particular way) - Can be defined in an implementation-independent way (that is, without relying on any particular GC algorithm or VM implementation) - Can give information about both live and dead Java objects JDK-8192891: NotifyFramePop Request Is Not Cleared if JVMTI_EVENT_FRAME_POP Is Disabled In the previous release, a NotifyFramePop request was only cleared when the `JVMTI_EVENT_FRAME_POP` was enabled. Now it is always cleared when the corresponding frame is popped, regardless of whether the `JVMTI_EVENT_FRAME_POP` is enabled or not. JDK-8210680: JEP 331: Low-Overhead Heap Profiling Provide a low-overhead way of sampling Java heap allocations, accessible via JVMTI ([JEP 331](http://openjdk.java.net/jeps/331)). It is designed to meet the following goals: - Low-overhead enough to be continuously enabled by default - Accessible via a well-defined, programmatic interface (JVMTI) - Can sample all allocations (that is, not limited to allocations that are in one particular heap region or that were allocated in one particular way) - Can be defined in an implementation-independent way (that is, without relying on any particular GC algorithm or VM implementation) - Can give information about both live and dead Java objects JDK-8192891: NotifyFramePop Request Is Not Cleared if JVMTI_EVENT_FRAME_POP Is Disabled In the previous release, a NotifyFramePop request was only cleared when the `JVMTI_EVENT_FRAME_POP` was enabled. Now it is always cleared when the corresponding frame is popped, regardless of whether the `JVMTI_EVENT_FRAME_POP` is enabled or not. core-libs/java.util:i18n: JDK-8200279: Removal of sun.locale.formatasdefault Property The system property `sun.locale.formatasdefault`, introduced in JDK 7 for backwards compatibility, has been removed. JDK-8203868: Updated Locale Data to Unicode CLDR v33 The locale data based on the Unicode Consortium's CLDR (Common Locale Data Registry) has been updated for JDK 11. Localized digits that are in supplementary planes (such as, those in Indian Chakma script) are substituted with ASCII digits until JDK-8204092 is resolved. Medium and short time patterns for Burmese locale have not been upgraded. When JDK-8209175 is resolved, these patterns will be upgraded. For more detail on CLDR release 33, please refer to [http://cldr.unicode.org/index/downloads/cldr-33](http://cldr.unicode.org/index/downloads/cldr-33). JDK-8200279: Removal of sun.locale.formatasdefault Property The system property `sun.locale.formatasdefault`, introduced in JDK 7 for backwards compatibility, has been removed. JDK-8203868: Updated Locale Data to Unicode CLDR v33 The locale data based on the Unicode Consortium's CLDR (Common Locale Data Registry) has been updated for JDK 11. Localized digits that are in supplementary planes (such as, those in Indian Chakma script) are substituted with ASCII digits until JDK-8204092 is resolved. Medium and short time patterns for Burmese locale have not been upgraded. When JDK-8209175 is resolved, these patterns will be upgraded. For more detail on CLDR release 33, please refer to [http://cldr.unicode.org/index/downloads/cldr-33](http://cldr.unicode.org/index/downloads/cldr-33). core-libs/java.lang: JDK-8209742: Method Class::getAnnotation Throws a TypeNotPresentException When the Annotation Class Is Not Present When `java.lang.Class::getAnnotation` is called to retrieve an annotation, and the annotation has an array value that references a missing class, attempting to read that value results in a `java.lang.TypeNotPresentException`. In previous releases the call to `Class::getAnnotation` incorrectly resulted in a `java.lang.ArrayStoreException`. Any programs that explicitly handled that exception should be updated to handle `java.lang.TypeNotPresentException` instead. JDK-8206908: Make Some System Properties Effectively readonly The values of `java.home`, `user.home`, `user.dir`, and `user.name` properties are cached at startup. Changes made using `System::setProperty` after startup will not change the behavior of APIs in the `java.base` module. JDK-8204259: Removal of Thread.destroy() and Thread.stop(Throwable) Methods The methods `Thread.destroy()` and `Thread.stop(Throwable)` have been removed. They have been deprecated for several Java SE releases. The `Thread.destroy()` method has never been implemented, and the `Thread.stop(Throwable)` method has been non-functional since Java SE 8. No code should rely on the behavior of these two methods; however, any code that uses these methods will cause compilation errors. The mitigation is to remove references to these methods from the source code. Note that the no-arg method `Thread.stop()` is unaffected by this change. JDK-8203660: java.lang.ref.Reference Does Not Support Cloning `java.lang.ref.Reference::clone` method always throws `CloneNotSupportedException`. `Reference` objects cannot be meaningfully cloned. To create a new Reference object, call the constructor to create a `Reference` object with the same referent and reference queue instead. JDK-8203484: JEP 327 Unicode 10 Upgrade existing platform APIs to support version 10.0 of the Unicode Standard ([JEP 327: Unicode 10](http://openjdk.java.net/jeps/327)). The JDK 11 release includes support for Unicode 10.0.0. Since the release of JDK 10, which supported Unicode 8.0.0, JDK 11 combines Unicode 9.0.0 and 10.0.0 versions including: - 16,018 new characters - 18 new blocks - 10 new scripts 16,018 new characters include important additions for: - 19 symbols for the new 4K TV standard
 - Bitcoin sign - 128 emoji characters 10 new scripts : - Adlam - Bhaiksuki - Marchen - Newa - Osage - Tangut - Masaram Gondi - Nushu - Soyombo - Zanabazar Square 18 new blocks which include 10 blocks for the new scripts listed above and 8 blocks for the following existing scripts: - Cyrillic Extended-C - Mongolian Supplement - Ideographic Symbols and Punctuation - Tangut Components - Glagolitic Supplement - Syriac Supplement - Kana Extended-A - CJK Extension F JDK-8209742: Method Class::getAnnotation Throws a TypeNotPresentException When the Annotation Class Is Not Present When `java.lang.Class::getAnnotation` is called to retrieve an annotation, and the annotation has an array value that references a missing class, attempting to read that value results in a `java.lang.TypeNotPresentException`. In previous releases the call to `Class::getAnnotation` incorrectly resulted in a `java.lang.ArrayStoreException`. Any programs that explicitly handled that exception should be updated to handle `java.lang.TypeNotPresentException` instead. JDK-8206908: Make Some System Properties Effectively readonly The values of `java.home`, `user.home`, `user.dir`, and `user.name` properties are cached at startup. Changes made using `System::setProperty` after startup will not change the behavior of APIs in the `java.base` module. JDK-8204259: Removal of Thread.destroy() and Thread.stop(Throwable) Methods The methods `Thread.destroy()` and `Thread.stop(Throwable)` have been removed. They have been deprecated for several Java SE releases. The `Thread.destroy()` method has never been implemented, and the `Thread.stop(Throwable)` method has been non-functional since Java SE 8. No code should rely on the behavior of these two methods; however, any code that uses these methods will cause compilation errors. The mitigation is to remove references to these methods from the source code. Note that the no-arg method `Thread.stop()` is unaffected by this change. JDK-8203660: java.lang.ref.Reference Does Not Support Cloning `java.lang.ref.Reference::clone` method always throws `CloneNotSupportedException`. `Reference` objects cannot be meaningfully cloned. To create a new Reference object, call the constructor to create a `Reference` object with the same referent and reference queue instead. JDK-8203484: JEP 327 Unicode 10 Upgrade existing platform APIs to support version 10.0 of the Unicode Standard ([JEP 327: Unicode 10](http://openjdk.java.net/jeps/327)). The JDK 11 release includes support for Unicode 10.0.0. Since the release of JDK 10, which supported Unicode 8.0.0, JDK 11 combines Unicode 9.0.0 and 10.0.0 versions including: - 16,018 new characters - 18 new blocks - 10 new scripts 16,018 new characters include important additions for: - 19 symbols for the new 4K TV standard
 - Bitcoin sign - 128 emoji characters 10 new scripts : - Adlam - Bhaiksuki - Marchen - Newa - Osage - Tangut - Masaram Gondi - Nushu - Soyombo - Zanabazar Square 18 new blocks which include 10 blocks for the new scripts listed above and 8 blocks for the following existing scripts: - Cyrillic Extended-C - Mongolian Supplement - Ideographic Symbols and Punctuation - Tangut Components - Glagolitic Supplement - Syriac Supplement - Kana Extended-A - CJK Extension F JDK-8209742: Method Class::getAnnotation Throws a TypeNotPresentException When the Annotation Class Is Not Present When `java.lang.Class::getAnnotation` is called to retrieve an annotation, and the annotation has an array value that references a missing class, attempting to read that value results in a `java.lang.TypeNotPresentException`. In previous releases the call to `Class::getAnnotation` incorrectly resulted in a `java.lang.ArrayStoreException`. Any programs that explicitly handled that exception should be updated to handle `java.lang.TypeNotPresentException` instead. JDK-8206908: Make Some System Properties Effectively readonly The values of `java.home`, `user.home`, `user.dir`, and `user.name` properties are cached at startup. Changes made using `System::setProperty` after startup will not change the behavior of APIs in the `java.base` module. JDK-8204259: Removal of Thread.destroy() and Thread.stop(Throwable) Methods The methods `Thread.destroy()` and `Thread.stop(Throwable)` have been removed. They have been deprecated for several Java SE releases. The `Thread.destroy()` method has never been implemented, and the `Thread.stop(Throwable)` method has been non-functional since Java SE 8. No code should rely on the behavior of these two methods; however, any code that uses these methods will cause compilation errors. The mitigation is to remove references to these methods from the source code. Note that the no-arg method `Thread.stop()` is unaffected by this change. JDK-8203660: java.lang.ref.Reference Does Not Support Cloning `java.lang.ref.Reference::clone` method always throws `CloneNotSupportedException`. `Reference` objects cannot be meaningfully cloned. To create a new Reference object, call the constructor to create a `Reference` object with the same referent and reference queue instead. JDK-8203484: JEP 327 Unicode 10 Upgrade existing platform APIs to support version 10.0 of the Unicode Standard ([JEP 327: Unicode 10](http://openjdk.java.net/jeps/327)). The JDK 11 release includes support for Unicode 10.0.0. Since the release of JDK 10, which supported Unicode 8.0.0, JDK 11 combines Unicode 9.0.0 and 10.0.0 versions including: - 16,018 new characters - 18 new blocks - 10 new scripts 16,018 new characters include important additions for: - 19 symbols for the new 4K TV standard
 - Bitcoin sign - 128 emoji characters 10 new scripts : - Adlam - Bhaiksuki - Marchen - Newa - Osage - Tangut - Masaram Gondi - Nushu - Soyombo - Zanabazar Square 18 new blocks which include 10 blocks for the new scripts listed above and 8 blocks for the following existing scripts: - Cyrillic Extended-C - Mongolian Supplement - Ideographic Symbols and Punctuation - Tangut Components - Glagolitic Supplement - Syriac Supplement - Kana Extended-A - CJK Extension F JDK-8209742: Method Class::getAnnotation Throws a TypeNotPresentException When the Annotation Class Is Not Present When `java.lang.Class::getAnnotation` is called to retrieve an annotation, and the annotation has an array value that references a missing class, attempting to read that value results in a `java.lang.TypeNotPresentException`. In previous releases the call to `Class::getAnnotation` incorrectly resulted in a `java.lang.ArrayStoreException`. Any programs that explicitly handled that exception should be updated to handle `java.lang.TypeNotPresentException` instead. JDK-8206908: Make Some System Properties Effectively readonly The values of `java.home`, `user.home`, `user.dir`, and `user.name` properties are cached at startup. Changes made using `System::setProperty` after startup will not change the behavior of APIs in the `java.base` module. JDK-8204259: Removal of Thread.destroy() and Thread.stop(Throwable) Methods The methods `Thread.destroy()` and `Thread.stop(Throwable)` have been removed. They have been deprecated for several Java SE releases. The `Thread.destroy()` method has never been implemented, and the `Thread.stop(Throwable)` method has been non-functional since Java SE 8. No code should rely on the behavior of these two methods; however, any code that uses these methods will cause compilation errors. The mitigation is to remove references to these methods from the source code. Note that the no-arg method `Thread.stop()` is unaffected by this change. JDK-8203660: java.lang.ref.Reference Does Not Support Cloning `java.lang.ref.Reference::clone` method always throws `CloneNotSupportedException`. `Reference` objects cannot be meaningfully cloned. To create a new Reference object, call the constructor to create a `Reference` object with the same referent and reference queue instead. JDK-8203484: JEP 327 Unicode 10 Upgrade existing platform APIs to support version 10.0 of the Unicode Standard ([JEP 327: Unicode 10](http://openjdk.java.net/jeps/327)). The JDK 11 release includes support for Unicode 10.0.0. Since the release of JDK 10, which supported Unicode 8.0.0, JDK 11 combines Unicode 9.0.0 and 10.0.0 versions including: - 16,018 new characters - 18 new blocks - 10 new scripts 16,018 new characters include important additions for: - 19 symbols for the new 4K TV standard
 - Bitcoin sign - 128 emoji characters 10 new scripts : - Adlam - Bhaiksuki - Marchen - Newa - Osage - Tangut - Masaram Gondi - Nushu - Soyombo - Zanabazar Square 18 new blocks which include 10 blocks for the new scripts listed above and 8 blocks for the following existing scripts: - Cyrillic Extended-C - Mongolian Supplement - Ideographic Symbols and Punctuation - Tangut Components - Glagolitic Supplement - Syriac Supplement - Kana Extended-A - CJK Extension F JDK-8209742: Method Class::getAnnotation Throws a TypeNotPresentException When the Annotation Class Is Not Present When `java.lang.Class::getAnnotation` is called to retrieve an annotation, and the annotation has an array value that references a missing class, attempting to read that value results in a `java.lang.TypeNotPresentException`. In previous releases the call to `Class::getAnnotation` incorrectly resulted in a `java.lang.ArrayStoreException`. Any programs that explicitly handled that exception should be updated to handle `java.lang.TypeNotPresentException` instead. JDK-8206908: Make Some System Properties Effectively readonly The values of `java.home`, `user.home`, `user.dir`, and `user.name` properties are cached at startup. Changes made using `System::setProperty` after startup will not change the behavior of APIs in the `java.base` module. JDK-8204259: Removal of Thread.destroy() and Thread.stop(Throwable) Methods The methods `Thread.destroy()` and `Thread.stop(Throwable)` have been removed. They have been deprecated for several Java SE releases. The `Thread.destroy()` method has never been implemented, and the `Thread.stop(Throwable)` method has been non-functional since Java SE 8. No code should rely on the behavior of these two methods; however, any code that uses these methods will cause compilation errors. The mitigation is to remove references to these methods from the source code. Note that the no-arg method `Thread.stop()` is unaffected by this change. JDK-8203660: java.lang.ref.Reference Does Not Support Cloning `java.lang.ref.Reference::clone` method always throws `CloneNotSupportedException`. `Reference` objects cannot be meaningfully cloned. To create a new Reference object, call the constructor to create a `Reference` object with the same referent and reference queue instead. JDK-8203484: JEP 327 Unicode 10 Upgrade existing platform APIs to support version 10.0 of the Unicode Standard ([JEP 327: Unicode 10](http://openjdk.java.net/jeps/327)). The JDK 11 release includes support for Unicode 10.0.0. Since the release of JDK 10, which supported Unicode 8.0.0, JDK 11 combines Unicode 9.0.0 and 10.0.0 versions including: - 16,018 new characters - 18 new blocks - 10 new scripts 16,018 new characters include important additions for: - 19 symbols for the new 4K TV standard
 - Bitcoin sign - 128 emoji characters 10 new scripts : - Adlam - Bhaiksuki - Marchen - Newa - Osage - Tangut - Masaram Gondi - Nushu - Soyombo - Zanabazar Square 18 new blocks which include 10 blocks for the new scripts listed above and 8 blocks for the following existing scripts: - Cyrillic Extended-C - Mongolian Supplement - Ideographic Symbols and Punctuation - Tangut Components - Glagolitic Supplement - Syriac Supplement - Kana Extended-A - CJK Extension F security-libs/org.ietf.jgss: JDK-8203846: Deprecate Stream-Based GSSContext Methods The stream-based methods in `GSSContext` have been deprecated in this release since GSS-API works on opaque tokens and has not defined a wire protocol. This includes the overloaded forms of the `initSecContext`, `acceptSecContext`, `wrap`, `unwrap`, `getMIC`, and `verifyMIC` methods that have an `InputStream` argument. These methods have already been removed in RFC 8353. client-libs: JDK-8202161: Removal of appletviewer Launcher The `appletviewer` tool was deprecated in JDK 9 (see JDK-8074165) and removed in this release. core-svc/javax.management: JDK-8206402: Removal of JVM-MANAGEMENT-MIB.mib The specification for JVM monitoring and management through SNMP `JVM-MANAGEMENT-MIB.mib` has been removed. Customers can use JMX to monitor and manage a running JVM and to access the standard set of metrics and operations. hotspot/runtime: JDK-8205622: JFR Start Failure After AppCDS Archive Created with JFR StartFlightRecording JFR will be disabled with a warning message if it is enabled during CDS dumping. The user will see the following warning message: Java HotSpot(TM) 64-Bit Server VM warning: JFR will be disabled during CDS dumping if JFR is enabled during CDS dumping such as in the following command line: $java -Xshare:dump -XX:StartFlightRecording=dumponexit=true JDK-8198565: Extend Class Data Sharing (CDS) to Support the Module Path In JDK 11, Class Data Sharing (CDS) has been improved to support archiving classes from the module path. To create a CDS archive using the `--module-path` VM option, the command line syntax is as follows: $ java -Xshare:dump -XX:SharedClassListFile= \ -XX:SharedArchiveFile= \ --module-path= -m To run with a CDS archive using the `--module-path` VM option, the command line syntax is as follows: $ java -Xshare:on -XX:SharedArchiveFile= \ --module-path= -m The following table describes how the VM options related to module paths may be used along with the `-Xshare` option.
-Xshare:dump -Xshare:{on,auto}
--module-path1 <mp> Allowed Allowed2
--module Allowed Allowed
--add-module Allowed Allowed
--upgrade-module-path3 Disallowed (exits if specified) Allowed (disables CDS)
--patch-module4 Disallowed (exits if specified) Allowed (disables CDS)
--limit-modules5 Disallowed (exits if specified) Allowed (disables CDS)
1Although there are two ways of specifying a module in a `--module-path`, that is, modular `.jar` or exploded module, only modular `.jar` files are supported. 2Different <mp> may be specified during dump time vs run time. If an archived class `K` was loaded from `mp1.jar` at dump time, but changes in <mp> cause it to be available from a different `mp2.jar` at run time, then the archived version of `K` will be disregarded at run time; `K` will be loaded dynamically. 3Currently, only two system modules are upgradeable (`java.compiler` and `jdk.internal.vm.compiler`). These are seldom upgraded in production software. 4As documented in [JEP 261](http://openjdk.java.net/jeps/261), `--patch-module` is strongly discouraged for production use. 5`--limit-modules` is intended for testing purposes. It is seldom used in production software. If any one of `--upgrade-module-path`, `--patch-module`, or `--limit-modules` is specified at dump time, the following error will be printed and the JVM will exit. For example, if the `--limit-modules` option is specified at dump time, the user will see the following error: Error occurred during initialization of VM Cannot use the following option when dumping the shared archive: --limit-modules If any one of `--upgrade-module-path`, `--patch-module`, or `--limit-modules` is specified at run time, the following warning message will be printed indicating that CDS is disabled. For example, if the `--limit-modules` option is specified at run time, the user will see the following warning: Java HotSpot(TM) 64-Bit Server VM warning: CDS is disabled when the --limit-modules option is specified. A few other noteworthy things to mention: 1. Any valid combinations of `-cp` and `--module-path` are supported. 2. A non-empty directory in the module path causes a fatal error. The user will see the following error messages: Error: non-empty directory <directory> Hint: enable -Xlog:class+path=info to diagnose the failure Error occurred during initialization of VM Cannot have non-empty directory in paths 3. Unlike the class path, there's no restriction that the module path at dump time must be equal to or be a prefix of the module path at run time. 4. The archive is invalidated if an existing JAR in the module path is updated after archive generation. 5. Removing a JAR from the module path does not invalidate the shared archive. Archived classes from the removed JAR are not used at runtime. JDK-8203901: JEP 181: Nest-Based Access Control Introduce nests, an access-control context that aligns with the existing notion of nested types in the Java programming language ([JEP-181: Nest-based access control](http://openjdk.java.net/jeps/181)). In Java SE 11, the Java Virtual Machine supports the arrangement of classes and interfaces into a new access control context, called a _nest_. Nests allow classes and interfaces that are logically part of the same code entity, but which are compiled to distinct `class` files, to access each other's `private` members without the need for compilers to insert accessibility-broadening bridge methods. Nests are a low-level mechanism of the Java SE Platform; there are no changes to the access control rules of the Java programming language. The `javac` compiler has been updated to use nests when compiling nested classes and interfaces in Java source code, by generating new `class` files attributes that place a top-level class (or interface) and all its nested classes and interfaces in the same nest. The Java Virtual Machine has been updated to use these attributes when checking the accessibility of a `private` constructor, method, or field, including via core reflection and the `java.lang.invoke.MethodHandles.Lookup` API. Membership in a nest is exposed through the new `getNestHost` and `getNestMembers` methods of `java.lang.Class`. As nest membership is recorded in the `class` file of the top-level class or interface (the _nest host_), that `class` file must be present at run time to allow the access control checks to be performed. This is not normally a concern as the top-level class or interface is typically used directly. In some code where a top-level class or interface acts only as a holder for nested classes or interfaces, and is otherwise unused, packaging tools may have elided that `class` file from the distribution of a library or application. With nest-based access control, it is no longer possible to elide the top-level class or interface if any of the nested classes or interfaces require access to each other's `private` members — a `NoClassDefFoundError` or `ClassNotFoundException` will be thrown. JDK-8205536: Obsolete Support for Commercial Features The `-XX:+UnlockCommercialFeatures` and `-XX:+LogCommercialFeatures` command line arguments have been obsoleted, and will generate a warning message if used. The command line arguments used to control the use of and logging for commercial/licensed features in the VM. Since there are no such features anymore the command line arguments are no longer useful. Similarly, the `VM.unlock_commercial_features` and `VM.check_commercial_features` jcmd commands will also generate a warning message but have no additional effect. JDK-8203243: Better Stability with Older NUMA Libraries (-XX:+UseNuma) A fix included in JDK 8 Update 152 introduced a regression that might cause the HotSpot JVM to crash during startup when the UseNUMA flag is used on Linux systems with versions of libnuma older than 2.0.9. This issue has been resolved. JDK-8205622: JFR Start Failure After AppCDS Archive Created with JFR StartFlightRecording JFR will be disabled with a warning message if it is enabled during CDS dumping. The user will see the following warning message: Java HotSpot(TM) 64-Bit Server VM warning: JFR will be disabled during CDS dumping if JFR is enabled during CDS dumping such as in the following command line: $java -Xshare:dump -XX:StartFlightRecording=dumponexit=true JDK-8198565: Extend Class Data Sharing (CDS) to Support the Module Path In JDK 11, Class Data Sharing (CDS) has been improved to support archiving classes from the module path. To create a CDS archive using the `--module-path` VM option, the command line syntax is as follows: $ java -Xshare:dump -XX:SharedClassListFile= \ -XX:SharedArchiveFile= \ --module-path= -m To run with a CDS archive using the `--module-path` VM option, the command line syntax is as follows: $ java -Xshare:on -XX:SharedArchiveFile= \ --module-path= -m The following table describes how the VM options related to module paths may be used along with the `-Xshare` option.
-Xshare:dump -Xshare:{on,auto}
--module-path1 <mp> Allowed Allowed2
--module Allowed Allowed
--add-module Allowed Allowed
--upgrade-module-path3 Disallowed (exits if specified) Allowed (disables CDS)
--patch-module4 Disallowed (exits if specified) Allowed (disables CDS)
--limit-modules5 Disallowed (exits if specified) Allowed (disables CDS)
1Although there are two ways of specifying a module in a `--module-path`, that is, modular `.jar` or exploded module, only modular `.jar` files are supported. 2Different <mp> may be specified during dump time vs run time. If an archived class `K` was loaded from `mp1.jar` at dump time, but changes in <mp> cause it to be available from a different `mp2.jar` at run time, then the archived version of `K` will be disregarded at run time; `K` will be loaded dynamically. 3Currently, only two system modules are upgradeable (`java.compiler` and `jdk.internal.vm.compiler`). These are seldom upgraded in production software. 4As documented in [JEP 261](http://openjdk.java.net/jeps/261), `--patch-module` is strongly discouraged for production use. 5`--limit-modules` is intended for testing purposes. It is seldom used in production software. If any one of `--upgrade-module-path`, `--patch-module`, or `--limit-modules` is specified at dump time, the following error will be printed and the JVM will exit. For example, if the `--limit-modules` option is specified at dump time, the user will see the following error: Error occurred during initialization of VM Cannot use the following option when dumping the shared archive: --limit-modules If any one of `--upgrade-module-path`, `--patch-module`, or `--limit-modules` is specified at run time, the following warning message will be printed indicating that CDS is disabled. For example, if the `--limit-modules` option is specified at run time, the user will see the following warning: Java HotSpot(TM) 64-Bit Server VM warning: CDS is disabled when the --limit-modules option is specified. A few other noteworthy things to mention: 1. Any valid combinations of `-cp` and `--module-path` are supported. 2. A non-empty directory in the module path causes a fatal error. The user will see the following error messages: Error: non-empty directory <directory> Hint: enable -Xlog:class+path=info to diagnose the failure Error occurred during initialization of VM Cannot have non-empty directory in paths 3. Unlike the class path, there's no restriction that the module path at dump time must be equal to or be a prefix of the module path at run time. 4. The archive is invalidated if an existing JAR in the module path is updated after archive generation. 5. Removing a JAR from the module path does not invalidate the shared archive. Archived classes from the removed JAR are not used at runtime. JDK-8203901: JEP 181: Nest-Based Access Control Introduce nests, an access-control context that aligns with the existing notion of nested types in the Java programming language ([JEP-181: Nest-based access control](http://openjdk.java.net/jeps/181)). In Java SE 11, the Java Virtual Machine supports the arrangement of classes and interfaces into a new access control context, called a _nest_. Nests allow classes and interfaces that are logically part of the same code entity, but which are compiled to distinct `class` files, to access each other's `private` members without the need for compilers to insert accessibility-broadening bridge methods. Nests are a low-level mechanism of the Java SE Platform; there are no changes to the access control rules of the Java programming language. The `javac` compiler has been updated to use nests when compiling nested classes and interfaces in Java source code, by generating new `class` files attributes that place a top-level class (or interface) and all its nested classes and interfaces in the same nest. The Java Virtual Machine has been updated to use these attributes when checking the accessibility of a `private` constructor, method, or field, including via core reflection and the `java.lang.invoke.MethodHandles.Lookup` API. Membership in a nest is exposed through the new `getNestHost` and `getNestMembers` methods of `java.lang.Class`. As nest membership is recorded in the `class` file of the top-level class or interface (the _nest host_), that `class` file must be present at run time to allow the access control checks to be performed. This is not normally a concern as the top-level class or interface is typically used directly. In some code where a top-level class or interface acts only as a holder for nested classes or interfaces, and is otherwise unused, packaging tools may have elided that `class` file from the distribution of a library or application. With nest-based access control, it is no longer possible to elide the top-level class or interface if any of the nested classes or interfaces require access to each other's `private` members — a `NoClassDefFoundError` or `ClassNotFoundException` will be thrown. JDK-8205536: Obsolete Support for Commercial Features The `-XX:+UnlockCommercialFeatures` and `-XX:+LogCommercialFeatures` command line arguments have been obsoleted, and will generate a warning message if used. The command line arguments used to control the use of and logging for commercial/licensed features in the VM. Since there are no such features anymore the command line arguments are no longer useful. Similarly, the `VM.unlock_commercial_features` and `VM.check_commercial_features` jcmd commands will also generate a warning message but have no additional effect. JDK-8203243: Better Stability with Older NUMA Libraries (-XX:+UseNuma) A fix included in JDK 8 Update 152 introduced a regression that might cause the HotSpot JVM to crash during startup when the UseNUMA flag is used on Linux systems with versions of libnuma older than 2.0.9. This issue has been resolved. JDK-8205622: JFR Start Failure After AppCDS Archive Created with JFR StartFlightRecording JFR will be disabled with a warning message if it is enabled during CDS dumping. The user will see the following warning message: Java HotSpot(TM) 64-Bit Server VM warning: JFR will be disabled during CDS dumping if JFR is enabled during CDS dumping such as in the following command line: $java -Xshare:dump -XX:StartFlightRecording=dumponexit=true JDK-8198565: Extend Class Data Sharing (CDS) to Support the Module Path In JDK 11, Class Data Sharing (CDS) has been improved to support archiving classes from the module path. To create a CDS archive using the `--module-path` VM option, the command line syntax is as follows: $ java -Xshare:dump -XX:SharedClassListFile= \ -XX:SharedArchiveFile= \ --module-path= -m To run with a CDS archive using the `--module-path` VM option, the command line syntax is as follows: $ java -Xshare:on -XX:SharedArchiveFile= \ --module-path= -m The following table describes how the VM options related to module paths may be used along with the `-Xshare` option.
-Xshare:dump -Xshare:{on,auto}
--module-path1 <mp> Allowed Allowed2
--module Allowed Allowed
--add-module Allowed Allowed
--upgrade-module-path3 Disallowed (exits if specified) Allowed (disables CDS)
--patch-module4 Disallowed (exits if specified) Allowed (disables CDS)
--limit-modules5 Disallowed (exits if specified) Allowed (disables CDS)
1Although there are two ways of specifying a module in a `--module-path`, that is, modular `.jar` or exploded module, only modular `.jar` files are supported. 2Different <mp> may be specified during dump time vs run time. If an archived class `K` was loaded from `mp1.jar` at dump time, but changes in <mp> cause it to be available from a different `mp2.jar` at run time, then the archived version of `K` will be disregarded at run time; `K` will be loaded dynamically. 3Currently, only two system modules are upgradeable (`java.compiler` and `jdk.internal.vm.compiler`). These are seldom upgraded in production software. 4As documented in [JEP 261](http://openjdk.java.net/jeps/261), `--patch-module` is strongly discouraged for production use. 5`--limit-modules` is intended for testing purposes. It is seldom used in production software. If any one of `--upgrade-module-path`, `--patch-module`, or `--limit-modules` is specified at dump time, the following error will be printed and the JVM will exit. For example, if the `--limit-modules` option is specified at dump time, the user will see the following error: Error occurred during initialization of VM Cannot use the following option when dumping the shared archive: --limit-modules If any one of `--upgrade-module-path`, `--patch-module`, or `--limit-modules` is specified at run time, the following warning message will be printed indicating that CDS is disabled. For example, if the `--limit-modules` option is specified at run time, the user will see the following warning: Java HotSpot(TM) 64-Bit Server VM warning: CDS is disabled when the --limit-modules option is specified. A few other noteworthy things to mention: 1. Any valid combinations of `-cp` and `--module-path` are supported. 2. A non-empty directory in the module path causes a fatal error. The user will see the following error messages: Error: non-empty directory <directory> Hint: enable -Xlog:class+path=info to diagnose the failure Error occurred during initialization of VM Cannot have non-empty directory in paths 3. Unlike the class path, there's no restriction that the module path at dump time must be equal to or be a prefix of the module path at run time. 4. The archive is invalidated if an existing JAR in the module path is updated after archive generation. 5. Removing a JAR from the module path does not invalidate the shared archive. Archived classes from the removed JAR are not used at runtime. JDK-8203901: JEP 181: Nest-Based Access Control Introduce nests, an access-control context that aligns with the existing notion of nested types in the Java programming language ([JEP-181: Nest-based access control](http://openjdk.java.net/jeps/181)). In Java SE 11, the Java Virtual Machine supports the arrangement of classes and interfaces into a new access control context, called a _nest_. Nests allow classes and interfaces that are logically part of the same code entity, but which are compiled to distinct `class` files, to access each other's `private` members without the need for compilers to insert accessibility-broadening bridge methods. Nests are a low-level mechanism of the Java SE Platform; there are no changes to the access control rules of the Java programming language. The `javac` compiler has been updated to use nests when compiling nested classes and interfaces in Java source code, by generating new `class` files attributes that place a top-level class (or interface) and all its nested classes and interfaces in the same nest. The Java Virtual Machine has been updated to use these attributes when checking the accessibility of a `private` constructor, method, or field, including via core reflection and the `java.lang.invoke.MethodHandles.Lookup` API. Membership in a nest is exposed through the new `getNestHost` and `getNestMembers` methods of `java.lang.Class`. As nest membership is recorded in the `class` file of the top-level class or interface (the _nest host_), that `class` file must be present at run time to allow the access control checks to be performed. This is not normally a concern as the top-level class or interface is typically used directly. In some code where a top-level class or interface acts only as a holder for nested classes or interfaces, and is otherwise unused, packaging tools may have elided that `class` file from the distribution of a library or application. With nest-based access control, it is no longer possible to elide the top-level class or interface if any of the nested classes or interfaces require access to each other's `private` members — a `NoClassDefFoundError` or `ClassNotFoundException` will be thrown. JDK-8205536: Obsolete Support for Commercial Features The `-XX:+UnlockCommercialFeatures` and `-XX:+LogCommercialFeatures` command line arguments have been obsoleted, and will generate a warning message if used. The command line arguments used to control the use of and logging for commercial/licensed features in the VM. Since there are no such features anymore the command line arguments are no longer useful. Similarly, the `VM.unlock_commercial_features` and `VM.check_commercial_features` jcmd commands will also generate a warning message but have no additional effect. JDK-8203243: Better Stability with Older NUMA Libraries (-XX:+UseNuma) A fix included in JDK 8 Update 152 introduced a regression that might cause the HotSpot JVM to crash during startup when the UseNUMA flag is used on Linux systems with versions of libnuma older than 2.0.9. This issue has been resolved. JDK-8205622: JFR Start Failure After AppCDS Archive Created with JFR StartFlightRecording JFR will be disabled with a warning message if it is enabled during CDS dumping. The user will see the following warning message: Java HotSpot(TM) 64-Bit Server VM warning: JFR will be disabled during CDS dumping if JFR is enabled during CDS dumping such as in the following command line: $java -Xshare:dump -XX:StartFlightRecording=dumponexit=true JDK-8198565: Extend Class Data Sharing (CDS) to Support the Module Path In JDK 11, Class Data Sharing (CDS) has been improved to support archiving classes from the module path. To create a CDS archive using the `--module-path` VM option, the command line syntax is as follows: $ java -Xshare:dump -XX:SharedClassListFile= \ -XX:SharedArchiveFile= \ --module-path= -m To run with a CDS archive using the `--module-path` VM option, the command line syntax is as follows: $ java -Xshare:on -XX:SharedArchiveFile= \ --module-path= -m The following table describes how the VM options related to module paths may be used along with the `-Xshare` option.
-Xshare:dump -Xshare:{on,auto}
--module-path1 <mp> Allowed Allowed2
--module Allowed Allowed
--add-module Allowed Allowed
--upgrade-module-path3 Disallowed (exits if specified) Allowed (disables CDS)
--patch-module4 Disallowed (exits if specified) Allowed (disables CDS)
--limit-modules5 Disallowed (exits if specified) Allowed (disables CDS)
1Although there are two ways of specifying a module in a `--module-path`, that is, modular `.jar` or exploded module, only modular `.jar` files are supported. 2Different <mp> may be specified during dump time vs run time. If an archived class `K` was loaded from `mp1.jar` at dump time, but changes in <mp> cause it to be available from a different `mp2.jar` at run time, then the archived version of `K` will be disregarded at run time; `K` will be loaded dynamically. 3Currently, only two system modules are upgradeable (`java.compiler` and `jdk.internal.vm.compiler`). These are seldom upgraded in production software. 4As documented in [JEP 261](http://openjdk.java.net/jeps/261), `--patch-module` is strongly discouraged for production use. 5`--limit-modules` is intended for testing purposes. It is seldom used in production software. If any one of `--upgrade-module-path`, `--patch-module`, or `--limit-modules` is specified at dump time, the following error will be printed and the JVM will exit. For example, if the `--limit-modules` option is specified at dump time, the user will see the following error: Error occurred during initialization of VM Cannot use the following option when dumping the shared archive: --limit-modules If any one of `--upgrade-module-path`, `--patch-module`, or `--limit-modules` is specified at run time, the following warning message will be printed indicating that CDS is disabled. For example, if the `--limit-modules` option is specified at run time, the user will see the following warning: Java HotSpot(TM) 64-Bit Server VM warning: CDS is disabled when the --limit-modules option is specified. A few other noteworthy things to mention: 1. Any valid combinations of `-cp` and `--module-path` are supported. 2. A non-empty directory in the module path causes a fatal error. The user will see the following error messages: Error: non-empty directory <directory> Hint: enable -Xlog:class+path=info to diagnose the failure Error occurred during initialization of VM Cannot have non-empty directory in paths 3. Unlike the class path, there's no restriction that the module path at dump time must be equal to or be a prefix of the module path at run time. 4. The archive is invalidated if an existing JAR in the module path is updated after archive generation. 5. Removing a JAR from the module path does not invalidate the shared archive. Archived classes from the removed JAR are not used at runtime. JDK-8203901: JEP 181: Nest-Based Access Control Introduce nests, an access-control context that aligns with the existing notion of nested types in the Java programming language ([JEP-181: Nest-based access control](http://openjdk.java.net/jeps/181)). In Java SE 11, the Java Virtual Machine supports the arrangement of classes and interfaces into a new access control context, called a _nest_. Nests allow classes and interfaces that are logically part of the same code entity, but which are compiled to distinct `class` files, to access each other's `private` members without the need for compilers to insert accessibility-broadening bridge methods. Nests are a low-level mechanism of the Java SE Platform; there are no changes to the access control rules of the Java programming language. The `javac` compiler has been updated to use nests when compiling nested classes and interfaces in Java source code, by generating new `class` files attributes that place a top-level class (or interface) and all its nested classes and interfaces in the same nest. The Java Virtual Machine has been updated to use these attributes when checking the accessibility of a `private` constructor, method, or field, including via core reflection and the `java.lang.invoke.MethodHandles.Lookup` API. Membership in a nest is exposed through the new `getNestHost` and `getNestMembers` methods of `java.lang.Class`. As nest membership is recorded in the `class` file of the top-level class or interface (the _nest host_), that `class` file must be present at run time to allow the access control checks to be performed. This is not normally a concern as the top-level class or interface is typically used directly. In some code where a top-level class or interface acts only as a holder for nested classes or interfaces, and is otherwise unused, packaging tools may have elided that `class` file from the distribution of a library or application. With nest-based access control, it is no longer possible to elide the top-level class or interface if any of the nested classes or interfaces require access to each other's `private` members — a `NoClassDefFoundError` or `ClassNotFoundException` will be thrown. JDK-8205536: Obsolete Support for Commercial Features The `-XX:+UnlockCommercialFeatures` and `-XX:+LogCommercialFeatures` command line arguments have been obsoleted, and will generate a warning message if used. The command line arguments used to control the use of and logging for commercial/licensed features in the VM. Since there are no such features anymore the command line arguments are no longer useful. Similarly, the `VM.unlock_commercial_features` and `VM.check_commercial_features` jcmd commands will also generate a warning message but have no additional effect. JDK-8203243: Better Stability with Older NUMA Libraries (-XX:+UseNuma) A fix included in JDK 8 Update 152 introduced a regression that might cause the HotSpot JVM to crash during startup when the UseNUMA flag is used on Linux systems with versions of libnuma older than 2.0.9. This issue has been resolved. JDK-8205622: JFR Start Failure After AppCDS Archive Created with JFR StartFlightRecording JFR will be disabled with a warning message if it is enabled during CDS dumping. The user will see the following warning message: Java HotSpot(TM) 64-Bit Server VM warning: JFR will be disabled during CDS dumping if JFR is enabled during CDS dumping such as in the following command line: $java -Xshare:dump -XX:StartFlightRecording=dumponexit=true JDK-8198565: Extend Class Data Sharing (CDS) to Support the Module Path In JDK 11, Class Data Sharing (CDS) has been improved to support archiving classes from the module path. To create a CDS archive using the `--module-path` VM option, the command line syntax is as follows: $ java -Xshare:dump -XX:SharedClassListFile= \ -XX:SharedArchiveFile= \ --module-path= -m To run with a CDS archive using the `--module-path` VM option, the command line syntax is as follows: $ java -Xshare:on -XX:SharedArchiveFile= \ --module-path= -m The following table describes how the VM options related to module paths may be used along with the `-Xshare` option.
-Xshare:dump -Xshare:{on,auto}
--module-path1 <mp> Allowed Allowed2
--module Allowed Allowed
--add-module Allowed Allowed
--upgrade-module-path3 Disallowed (exits if specified) Allowed (disables CDS)
--patch-module4 Disallowed (exits if specified) Allowed (disables CDS)
--limit-modules5 Disallowed (exits if specified) Allowed (disables CDS)
1Although there are two ways of specifying a module in a `--module-path`, that is, modular `.jar` or exploded module, only modular `.jar` files are supported. 2Different <mp> may be specified during dump time vs run time. If an archived class `K` was loaded from `mp1.jar` at dump time, but changes in <mp> cause it to be available from a different `mp2.jar` at run time, then the archived version of `K` will be disregarded at run time; `K` will be loaded dynamically. 3Currently, only two system modules are upgradeable (`java.compiler` and `jdk.internal.vm.compiler`). These are seldom upgraded in production software. 4As documented in [JEP 261](http://openjdk.java.net/jeps/261), `--patch-module` is strongly discouraged for production use. 5`--limit-modules` is intended for testing purposes. It is seldom used in production software. If any one of `--upgrade-module-path`, `--patch-module`, or `--limit-modules` is specified at dump time, the following error will be printed and the JVM will exit. For example, if the `--limit-modules` option is specified at dump time, the user will see the following error: Error occurred during initialization of VM Cannot use the following option when dumping the shared archive: --limit-modules If any one of `--upgrade-module-path`, `--patch-module`, or `--limit-modules` is specified at run time, the following warning message will be printed indicating that CDS is disabled. For example, if the `--limit-modules` option is specified at run time, the user will see the following warning: Java HotSpot(TM) 64-Bit Server VM warning: CDS is disabled when the --limit-modules option is specified. A few other noteworthy things to mention: 1. Any valid combinations of `-cp` and `--module-path` are supported. 2. A non-empty directory in the module path causes a fatal error. The user will see the following error messages: Error: non-empty directory <directory> Hint: enable -Xlog:class+path=info to diagnose the failure Error occurred during initialization of VM Cannot have non-empty directory in paths 3. Unlike the class path, there's no restriction that the module path at dump time must be equal to or be a prefix of the module path at run time. 4. The archive is invalidated if an existing JAR in the module path is updated after archive generation. 5. Removing a JAR from the module path does not invalidate the shared archive. Archived classes from the removed JAR are not used at runtime. JDK-8203901: JEP 181: Nest-Based Access Control Introduce nests, an access-control context that aligns with the existing notion of nested types in the Java programming language ([JEP-181: Nest-based access control](http://openjdk.java.net/jeps/181)). In Java SE 11, the Java Virtual Machine supports the arrangement of classes and interfaces into a new access control context, called a _nest_. Nests allow classes and interfaces that are logically part of the same code entity, but which are compiled to distinct `class` files, to access each other's `private` members without the need for compilers to insert accessibility-broadening bridge methods. Nests are a low-level mechanism of the Java SE Platform; there are no changes to the access control rules of the Java programming language. The `javac` compiler has been updated to use nests when compiling nested classes and interfaces in Java source code, by generating new `class` files attributes that place a top-level class (or interface) and all its nested classes and interfaces in the same nest. The Java Virtual Machine has been updated to use these attributes when checking the accessibility of a `private` constructor, method, or field, including via core reflection and the `java.lang.invoke.MethodHandles.Lookup` API. Membership in a nest is exposed through the new `getNestHost` and `getNestMembers` methods of `java.lang.Class`. As nest membership is recorded in the `class` file of the top-level class or interface (the _nest host_), that `class` file must be present at run time to allow the access control checks to be performed. This is not normally a concern as the top-level class or interface is typically used directly. In some code where a top-level class or interface acts only as a holder for nested classes or interfaces, and is otherwise unused, packaging tools may have elided that `class` file from the distribution of a library or application. With nest-based access control, it is no longer possible to elide the top-level class or interface if any of the nested classes or interfaces require access to each other's `private` members — a `NoClassDefFoundError` or `ClassNotFoundException` will be thrown. JDK-8205536: Obsolete Support for Commercial Features The `-XX:+UnlockCommercialFeatures` and `-XX:+LogCommercialFeatures` command line arguments have been obsoleted, and will generate a warning message if used. The command line arguments used to control the use of and logging for commercial/licensed features in the VM. Since there are no such features anymore the command line arguments are no longer useful. Similarly, the `VM.unlock_commercial_features` and `VM.check_commercial_features` jcmd commands will also generate a warning message but have no additional effect. JDK-8203243: Better Stability with Older NUMA Libraries (-XX:+UseNuma) A fix included in JDK 8 Update 152 introduced a regression that might cause the HotSpot JVM to crash during startup when the UseNUMA flag is used on Linux systems with versions of libnuma older than 2.0.9. This issue has been resolved. core-libs/java.lang.module: JDK-8205168: Change to Policy for the Default Set of Modules Resolved When Compiling or Running Code on the Class Path The default set of root modules when compiling code or running code on the class path has changed in JDK 11 to be all observable system modules that export an API. The only observable change is that the `java.se` module is no longer resolved by default. core-libs/java.util:collections: JDK-8206941: New Collection.toArray(IntFunction) Default Method A new default method `toArray(IntFunction)` has been added to the `java.util.Collection` interface. This method allows the collection's elements to be transferred to a newly created array of a desired runtime type. The new method is an overload of the existing `toArray(T[])` method that takes an array instance as an argument. The addition of the overloaded method creates a minor source incompatibility. Previously, code of the form `coll.toArray(null)` would always resolve to the existing `toArray` method. With the new overloaded method, this code is now ambiguous and will result in a compile-time error. (This is only a source incompatibility. Existing binaries are unaffected.) The ambiguous code should be changed to cast `null` to the desired array type, for example, `toArray((Object[])null)` or some other array type. Note that passing `null` to either `toArray` method is specified to throw `NullPointerException`. security-libs/java.security: JDK-8209512: Added Google Trust Services GlobalSign Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + Google + globalsigneccrootcar4 DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4 + globalsignr2ca DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2 JDK-8207191: Added T-Systems, GlobalSign and Starfield Services Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + T-Systems + deutschetelekomrootca2 DN: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche Telekom AG, C=DE + ttelesecglobalrootclass3ca DN: CN=T-TeleSec GlobalRoot Class 3, OU=T-Systems Trust Center, O=T-Systems Enterprise Services GmbH, C=DE + ttelesecglobalrootclass2ca DN: CN=T-TeleSec GlobalRoot Class 2, OU=T-Systems Trust Center, O=T-Systems Enterprise Services GmbH, C=DE + Amazon + starfieldservicesrootg2ca DN: CN=Starfield Services Root Certificate Authority - G2, O="Starfield Technologies, Inc.", L=Scottsdale, ST=Arizona, C=US + GlobalSign + globalsignca DN: CN=GlobalSign Root CA, OU=Root CA, O=GlobalSign nv-sa, C=BE + globalsignr3ca DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R3 + globalsigneccrootcar5 DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R5 JDK-8204124: Added GoDaddy Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + GoDaddy + godaddyrootg2ca DN: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2 + godaddyclass2ca DN: C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certification Authority + starfieldclass2ca DN: C=US, O=Starfield Technologies, Inc., OU=Starfield Class 2 Certification Authority + starfieldrootg2ca DN: C=US, ST=Arizona, L=Scottsdale, O=Starfield Technologies, Inc., CN=Starfield Root Certificate Authority - G2 JDK-8204102: Removal of Several Symantec Root CAs The following Symantec root certificates are no longer in use and have been removed: + Symantec + equifaxsecureca DN: OU=Equifax Secure Certificate Authority, O=Equifax, C=US + equifaxsecureglobalebusinessca1 DN: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US + equifaxsecureebusinessca1 DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US + verisignclass1g3ca DN: CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US + verisignclass2g3ca DN: CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US + verisignclass1g2ca DN: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US + verisignclass1ca DN: OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US JDK-8197783: jarsigner Prints When a timestamp Will Expire The `jarsigner` tool now shows more information about the lifetime of a timestamped JAR. New warning and error messages are displayed when a timestamp has expired or is expiring within one year. JDK-8205949: Added Entrust Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + Entrust + entrustrootcaec1 DN: C=US, O=Entrust, Inc., OU=See www.entrust.net/legal-terms, OU=(c) 2012 Entrust, Inc. - for authorized use only, CN=Entrust Root Certification Authority - EC1 + entrust2048ca DN: O=Entrust.net, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Certification Authority (2048) + entrustrootcag2 DN: C=US, O=Entrust, Inc., OU=See www.entrust.net/legal-terms, OU=(c) 2009 Entrust, Inc. - for authorized use only, CN=Entrust Root Certification Authority - G2 + entrustevca DN: C=US, O=Entrust, Inc., OU=www.entrust.net/CPS is incorporated by reference, OU=(c) 2006 Entrust, Inc., CN=Entrust Root Certification Authority + affirmtrustnetworkingca DN: C=US, O=AffirmTrust, CN=AffirmTrust Networking + affirmtrustpremiumca DN: C=US, O=AffirmTrust, CN=AffirmTrust Premium + affirmtrustcommercialca DN: C=US, O=AffirmTrust, CN=AffirmTrust Commercial + affirmtrustpremiumeccca DN: C=US, O=AffirmTrust, CN=AffirmTrust Premium ECC JDK-8229518: Added Support for PKCS#1 v2.2 Algorithms Including RSASSA-PSS Signature The SunRsaSign and SunJCE providers have been enhanced with support for more algorithms defined in PKCS#1 v2.2, such as RSASSA-PSS signature and OAEP using FIPS 180-4 digest algorithms. New constructors and methods have been added to relevant JCA/JCE classes under the `java.security.spec` and `javax.crypto.spec` packages for supporting additional RSASSA-PSS parameters. JDK-8204487: Removal of Baltimore Cybertrust Code Signing CA The following Baltimore CyberTrust Code Signing root certificate is no longer in use and has been removed: + baltimorecodesigningca DN: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE JDK-8207255: Removal of AOL and Swisscom Root Certificates The following root certificates have been removed from the cacerts truststore: + AOL + aolrootca1 DN: CN=America Online Root Certification Authority 1, O=America Online Inc., C=US + aolrootca2 DN: CN=America Online Root Certification Authority 2, O=America Online Inc., C=US + Swisscom + swisscomrootca2 DN: CN=Swisscom Root CA 2, OU=Digital Certificate Services, O=Swisscom, C=ch JDK-8204489: Removal of SECOM Root Certificate The following SECOM root certificate is no longer in use and has been removed: + secomevrootca1 DN: OU=Security Communication EV RootCA1, O="SECOM Trust Systems CO.,LTD.", C=JP JDK-8209512: Added Google Trust Services GlobalSign Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + Google + globalsigneccrootcar4 DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4 + globalsignr2ca DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2 JDK-8207191: Added T-Systems, GlobalSign and Starfield Services Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + T-Systems + deutschetelekomrootca2 DN: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche Telekom AG, C=DE + ttelesecglobalrootclass3ca DN: CN=T-TeleSec GlobalRoot Class 3, OU=T-Systems Trust Center, O=T-Systems Enterprise Services GmbH, C=DE + ttelesecglobalrootclass2ca DN: CN=T-TeleSec GlobalRoot Class 2, OU=T-Systems Trust Center, O=T-Systems Enterprise Services GmbH, C=DE + Amazon + starfieldservicesrootg2ca DN: CN=Starfield Services Root Certificate Authority - G2, O="Starfield Technologies, Inc.", L=Scottsdale, ST=Arizona, C=US + GlobalSign + globalsignca DN: CN=GlobalSign Root CA, OU=Root CA, O=GlobalSign nv-sa, C=BE + globalsignr3ca DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R3 + globalsigneccrootcar5 DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R5 JDK-8204124: Added GoDaddy Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + GoDaddy + godaddyrootg2ca DN: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2 + godaddyclass2ca DN: C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certification Authority + starfieldclass2ca DN: C=US, O=Starfield Technologies, Inc., OU=Starfield Class 2 Certification Authority + starfieldrootg2ca DN: C=US, ST=Arizona, L=Scottsdale, O=Starfield Technologies, Inc., CN=Starfield Root Certificate Authority - G2 JDK-8204102: Removal of Several Symantec Root CAs The following Symantec root certificates are no longer in use and have been removed: + Symantec + equifaxsecureca DN: OU=Equifax Secure Certificate Authority, O=Equifax, C=US + equifaxsecureglobalebusinessca1 DN: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US + equifaxsecureebusinessca1 DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US + verisignclass1g3ca DN: CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US + verisignclass2g3ca DN: CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US + verisignclass1g2ca DN: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US + verisignclass1ca DN: OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US JDK-8197783: jarsigner Prints When a timestamp Will Expire The `jarsigner` tool now shows more information about the lifetime of a timestamped JAR. New warning and error messages are displayed when a timestamp has expired or is expiring within one year. JDK-8205949: Added Entrust Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + Entrust + entrustrootcaec1 DN: C=US, O=Entrust, Inc., OU=See www.entrust.net/legal-terms, OU=(c) 2012 Entrust, Inc. - for authorized use only, CN=Entrust Root Certification Authority - EC1 + entrust2048ca DN: O=Entrust.net, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Certification Authority (2048) + entrustrootcag2 DN: C=US, O=Entrust, Inc., OU=See www.entrust.net/legal-terms, OU=(c) 2009 Entrust, Inc. - for authorized use only, CN=Entrust Root Certification Authority - G2 + entrustevca DN: C=US, O=Entrust, Inc., OU=www.entrust.net/CPS is incorporated by reference, OU=(c) 2006 Entrust, Inc., CN=Entrust Root Certification Authority + affirmtrustnetworkingca DN: C=US, O=AffirmTrust, CN=AffirmTrust Networking + affirmtrustpremiumca DN: C=US, O=AffirmTrust, CN=AffirmTrust Premium + affirmtrustcommercialca DN: C=US, O=AffirmTrust, CN=AffirmTrust Commercial + affirmtrustpremiumeccca DN: C=US, O=AffirmTrust, CN=AffirmTrust Premium ECC JDK-8229518: Added Support for PKCS#1 v2.2 Algorithms Including RSASSA-PSS Signature The SunRsaSign and SunJCE providers have been enhanced with support for more algorithms defined in PKCS#1 v2.2, such as RSASSA-PSS signature and OAEP using FIPS 180-4 digest algorithms. New constructors and methods have been added to relevant JCA/JCE classes under the `java.security.spec` and `javax.crypto.spec` packages for supporting additional RSASSA-PSS parameters. JDK-8204487: Removal of Baltimore Cybertrust Code Signing CA The following Baltimore CyberTrust Code Signing root certificate is no longer in use and has been removed: + baltimorecodesigningca DN: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE JDK-8207255: Removal of AOL and Swisscom Root Certificates The following root certificates have been removed from the cacerts truststore: + AOL + aolrootca1 DN: CN=America Online Root Certification Authority 1, O=America Online Inc., C=US + aolrootca2 DN: CN=America Online Root Certification Authority 2, O=America Online Inc., C=US + Swisscom + swisscomrootca2 DN: CN=Swisscom Root CA 2, OU=Digital Certificate Services, O=Swisscom, C=ch JDK-8204489: Removal of SECOM Root Certificate The following SECOM root certificate is no longer in use and has been removed: + secomevrootca1 DN: OU=Security Communication EV RootCA1, O="SECOM Trust Systems CO.,LTD.", C=JP JDK-8209512: Added Google Trust Services GlobalSign Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + Google + globalsigneccrootcar4 DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4 + globalsignr2ca DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2 JDK-8207191: Added T-Systems, GlobalSign and Starfield Services Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + T-Systems + deutschetelekomrootca2 DN: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche Telekom AG, C=DE + ttelesecglobalrootclass3ca DN: CN=T-TeleSec GlobalRoot Class 3, OU=T-Systems Trust Center, O=T-Systems Enterprise Services GmbH, C=DE + ttelesecglobalrootclass2ca DN: CN=T-TeleSec GlobalRoot Class 2, OU=T-Systems Trust Center, O=T-Systems Enterprise Services GmbH, C=DE + Amazon + starfieldservicesrootg2ca DN: CN=Starfield Services Root Certificate Authority - G2, O="Starfield Technologies, Inc.", L=Scottsdale, ST=Arizona, C=US + GlobalSign + globalsignca DN: CN=GlobalSign Root CA, OU=Root CA, O=GlobalSign nv-sa, C=BE + globalsignr3ca DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R3 + globalsigneccrootcar5 DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R5 JDK-8204124: Added GoDaddy Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + GoDaddy + godaddyrootg2ca DN: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2 + godaddyclass2ca DN: C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certification Authority + starfieldclass2ca DN: C=US, O=Starfield Technologies, Inc., OU=Starfield Class 2 Certification Authority + starfieldrootg2ca DN: C=US, ST=Arizona, L=Scottsdale, O=Starfield Technologies, Inc., CN=Starfield Root Certificate Authority - G2 JDK-8204102: Removal of Several Symantec Root CAs The following Symantec root certificates are no longer in use and have been removed: + Symantec + equifaxsecureca DN: OU=Equifax Secure Certificate Authority, O=Equifax, C=US + equifaxsecureglobalebusinessca1 DN: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US + equifaxsecureebusinessca1 DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US + verisignclass1g3ca DN: CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US + verisignclass2g3ca DN: CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US + verisignclass1g2ca DN: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US + verisignclass1ca DN: OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US JDK-8197783: jarsigner Prints When a timestamp Will Expire The `jarsigner` tool now shows more information about the lifetime of a timestamped JAR. New warning and error messages are displayed when a timestamp has expired or is expiring within one year. JDK-8205949: Added Entrust Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + Entrust + entrustrootcaec1 DN: C=US, O=Entrust, Inc., OU=See www.entrust.net/legal-terms, OU=(c) 2012 Entrust, Inc. - for authorized use only, CN=Entrust Root Certification Authority - EC1 + entrust2048ca DN: O=Entrust.net, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Certification Authority (2048) + entrustrootcag2 DN: C=US, O=Entrust, Inc., OU=See www.entrust.net/legal-terms, OU=(c) 2009 Entrust, Inc. - for authorized use only, CN=Entrust Root Certification Authority - G2 + entrustevca DN: C=US, O=Entrust, Inc., OU=www.entrust.net/CPS is incorporated by reference, OU=(c) 2006 Entrust, Inc., CN=Entrust Root Certification Authority + affirmtrustnetworkingca DN: C=US, O=AffirmTrust, CN=AffirmTrust Networking + affirmtrustpremiumca DN: C=US, O=AffirmTrust, CN=AffirmTrust Premium + affirmtrustcommercialca DN: C=US, O=AffirmTrust, CN=AffirmTrust Commercial + affirmtrustpremiumeccca DN: C=US, O=AffirmTrust, CN=AffirmTrust Premium ECC JDK-8229518: Added Support for PKCS#1 v2.2 Algorithms Including RSASSA-PSS Signature The SunRsaSign and SunJCE providers have been enhanced with support for more algorithms defined in PKCS#1 v2.2, such as RSASSA-PSS signature and OAEP using FIPS 180-4 digest algorithms. New constructors and methods have been added to relevant JCA/JCE classes under the `java.security.spec` and `javax.crypto.spec` packages for supporting additional RSASSA-PSS parameters. JDK-8204487: Removal of Baltimore Cybertrust Code Signing CA The following Baltimore CyberTrust Code Signing root certificate is no longer in use and has been removed: + baltimorecodesigningca DN: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE JDK-8207255: Removal of AOL and Swisscom Root Certificates The following root certificates have been removed from the cacerts truststore: + AOL + aolrootca1 DN: CN=America Online Root Certification Authority 1, O=America Online Inc., C=US + aolrootca2 DN: CN=America Online Root Certification Authority 2, O=America Online Inc., C=US + Swisscom + swisscomrootca2 DN: CN=Swisscom Root CA 2, OU=Digital Certificate Services, O=Swisscom, C=ch JDK-8204489: Removal of SECOM Root Certificate The following SECOM root certificate is no longer in use and has been removed: + secomevrootca1 DN: OU=Security Communication EV RootCA1, O="SECOM Trust Systems CO.,LTD.", C=JP JDK-8209512: Added Google Trust Services GlobalSign Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + Google + globalsigneccrootcar4 DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4 + globalsignr2ca DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2 JDK-8207191: Added T-Systems, GlobalSign and Starfield Services Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + T-Systems + deutschetelekomrootca2 DN: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche Telekom AG, C=DE + ttelesecglobalrootclass3ca DN: CN=T-TeleSec GlobalRoot Class 3, OU=T-Systems Trust Center, O=T-Systems Enterprise Services GmbH, C=DE + ttelesecglobalrootclass2ca DN: CN=T-TeleSec GlobalRoot Class 2, OU=T-Systems Trust Center, O=T-Systems Enterprise Services GmbH, C=DE + Amazon + starfieldservicesrootg2ca DN: CN=Starfield Services Root Certificate Authority - G2, O="Starfield Technologies, Inc.", L=Scottsdale, ST=Arizona, C=US + GlobalSign + globalsignca DN: CN=GlobalSign Root CA, OU=Root CA, O=GlobalSign nv-sa, C=BE + globalsignr3ca DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R3 + globalsigneccrootcar5 DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R5 JDK-8204124: Added GoDaddy Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + GoDaddy + godaddyrootg2ca DN: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2 + godaddyclass2ca DN: C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certification Authority + starfieldclass2ca DN: C=US, O=Starfield Technologies, Inc., OU=Starfield Class 2 Certification Authority + starfieldrootg2ca DN: C=US, ST=Arizona, L=Scottsdale, O=Starfield Technologies, Inc., CN=Starfield Root Certificate Authority - G2 JDK-8204102: Removal of Several Symantec Root CAs The following Symantec root certificates are no longer in use and have been removed: + Symantec + equifaxsecureca DN: OU=Equifax Secure Certificate Authority, O=Equifax, C=US + equifaxsecureglobalebusinessca1 DN: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US + equifaxsecureebusinessca1 DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US + verisignclass1g3ca DN: CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US + verisignclass2g3ca DN: CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US + verisignclass1g2ca DN: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US + verisignclass1ca DN: OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US JDK-8197783: jarsigner Prints When a timestamp Will Expire The `jarsigner` tool now shows more information about the lifetime of a timestamped JAR. New warning and error messages are displayed when a timestamp has expired or is expiring within one year. JDK-8205949: Added Entrust Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + Entrust + entrustrootcaec1 DN: C=US, O=Entrust, Inc., OU=See www.entrust.net/legal-terms, OU=(c) 2012 Entrust, Inc. - for authorized use only, CN=Entrust Root Certification Authority - EC1 + entrust2048ca DN: O=Entrust.net, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Certification Authority (2048) + entrustrootcag2 DN: C=US, O=Entrust, Inc., OU=See www.entrust.net/legal-terms, OU=(c) 2009 Entrust, Inc. - for authorized use only, CN=Entrust Root Certification Authority - G2 + entrustevca DN: C=US, O=Entrust, Inc., OU=www.entrust.net/CPS is incorporated by reference, OU=(c) 2006 Entrust, Inc., CN=Entrust Root Certification Authority + affirmtrustnetworkingca DN: C=US, O=AffirmTrust, CN=AffirmTrust Networking + affirmtrustpremiumca DN: C=US, O=AffirmTrust, CN=AffirmTrust Premium + affirmtrustcommercialca DN: C=US, O=AffirmTrust, CN=AffirmTrust Commercial + affirmtrustpremiumeccca DN: C=US, O=AffirmTrust, CN=AffirmTrust Premium ECC JDK-8229518: Added Support for PKCS#1 v2.2 Algorithms Including RSASSA-PSS Signature The SunRsaSign and SunJCE providers have been enhanced with support for more algorithms defined in PKCS#1 v2.2, such as RSASSA-PSS signature and OAEP using FIPS 180-4 digest algorithms. New constructors and methods have been added to relevant JCA/JCE classes under the `java.security.spec` and `javax.crypto.spec` packages for supporting additional RSASSA-PSS parameters. JDK-8204487: Removal of Baltimore Cybertrust Code Signing CA The following Baltimore CyberTrust Code Signing root certificate is no longer in use and has been removed: + baltimorecodesigningca DN: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE JDK-8207255: Removal of AOL and Swisscom Root Certificates The following root certificates have been removed from the cacerts truststore: + AOL + aolrootca1 DN: CN=America Online Root Certification Authority 1, O=America Online Inc., C=US + aolrootca2 DN: CN=America Online Root Certification Authority 2, O=America Online Inc., C=US + Swisscom + swisscomrootca2 DN: CN=Swisscom Root CA 2, OU=Digital Certificate Services, O=Swisscom, C=ch JDK-8204489: Removal of SECOM Root Certificate The following SECOM root certificate is no longer in use and has been removed: + secomevrootca1 DN: OU=Security Communication EV RootCA1, O="SECOM Trust Systems CO.,LTD.", C=JP JDK-8209512: Added Google Trust Services GlobalSign Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + Google + globalsigneccrootcar4 DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4 + globalsignr2ca DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2 JDK-8207191: Added T-Systems, GlobalSign and Starfield Services Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + T-Systems + deutschetelekomrootca2 DN: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche Telekom AG, C=DE + ttelesecglobalrootclass3ca DN: CN=T-TeleSec GlobalRoot Class 3, OU=T-Systems Trust Center, O=T-Systems Enterprise Services GmbH, C=DE + ttelesecglobalrootclass2ca DN: CN=T-TeleSec GlobalRoot Class 2, OU=T-Systems Trust Center, O=T-Systems Enterprise Services GmbH, C=DE + Amazon + starfieldservicesrootg2ca DN: CN=Starfield Services Root Certificate Authority - G2, O="Starfield Technologies, Inc.", L=Scottsdale, ST=Arizona, C=US + GlobalSign + globalsignca DN: CN=GlobalSign Root CA, OU=Root CA, O=GlobalSign nv-sa, C=BE + globalsignr3ca DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R3 + globalsigneccrootcar5 DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R5 JDK-8204124: Added GoDaddy Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + GoDaddy + godaddyrootg2ca DN: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2 + godaddyclass2ca DN: C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certification Authority + starfieldclass2ca DN: C=US, O=Starfield Technologies, Inc., OU=Starfield Class 2 Certification Authority + starfieldrootg2ca DN: C=US, ST=Arizona, L=Scottsdale, O=Starfield Technologies, Inc., CN=Starfield Root Certificate Authority - G2 JDK-8204102: Removal of Several Symantec Root CAs The following Symantec root certificates are no longer in use and have been removed: + Symantec + equifaxsecureca DN: OU=Equifax Secure Certificate Authority, O=Equifax, C=US + equifaxsecureglobalebusinessca1 DN: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US + equifaxsecureebusinessca1 DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US + verisignclass1g3ca DN: CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US + verisignclass2g3ca DN: CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US + verisignclass1g2ca DN: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US + verisignclass1ca DN: OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US JDK-8197783: jarsigner Prints When a timestamp Will Expire The `jarsigner` tool now shows more information about the lifetime of a timestamped JAR. New warning and error messages are displayed when a timestamp has expired or is expiring within one year. JDK-8205949: Added Entrust Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + Entrust + entrustrootcaec1 DN: C=US, O=Entrust, Inc., OU=See www.entrust.net/legal-terms, OU=(c) 2012 Entrust, Inc. - for authorized use only, CN=Entrust Root Certification Authority - EC1 + entrust2048ca DN: O=Entrust.net, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Certification Authority (2048) + entrustrootcag2 DN: C=US, O=Entrust, Inc., OU=See www.entrust.net/legal-terms, OU=(c) 2009 Entrust, Inc. - for authorized use only, CN=Entrust Root Certification Authority - G2 + entrustevca DN: C=US, O=Entrust, Inc., OU=www.entrust.net/CPS is incorporated by reference, OU=(c) 2006 Entrust, Inc., CN=Entrust Root Certification Authority + affirmtrustnetworkingca DN: C=US, O=AffirmTrust, CN=AffirmTrust Networking + affirmtrustpremiumca DN: C=US, O=AffirmTrust, CN=AffirmTrust Premium + affirmtrustcommercialca DN: C=US, O=AffirmTrust, CN=AffirmTrust Commercial + affirmtrustpremiumeccca DN: C=US, O=AffirmTrust, CN=AffirmTrust Premium ECC JDK-8229518: Added Support for PKCS#1 v2.2 Algorithms Including RSASSA-PSS Signature The SunRsaSign and SunJCE providers have been enhanced with support for more algorithms defined in PKCS#1 v2.2, such as RSASSA-PSS signature and OAEP using FIPS 180-4 digest algorithms. New constructors and methods have been added to relevant JCA/JCE classes under the `java.security.spec` and `javax.crypto.spec` packages for supporting additional RSASSA-PSS parameters. JDK-8204487: Removal of Baltimore Cybertrust Code Signing CA The following Baltimore CyberTrust Code Signing root certificate is no longer in use and has been removed: + baltimorecodesigningca DN: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE JDK-8207255: Removal of AOL and Swisscom Root Certificates The following root certificates have been removed from the cacerts truststore: + AOL + aolrootca1 DN: CN=America Online Root Certification Authority 1, O=America Online Inc., C=US + aolrootca2 DN: CN=America Online Root Certification Authority 2, O=America Online Inc., C=US + Swisscom + swisscomrootca2 DN: CN=Swisscom Root CA 2, OU=Digital Certificate Services, O=Swisscom, C=ch JDK-8204489: Removal of SECOM Root Certificate The following SECOM root certificate is no longer in use and has been removed: + secomevrootca1 DN: OU=Security Communication EV RootCA1, O="SECOM Trust Systems CO.,LTD.", C=JP JDK-8209512: Added Google Trust Services GlobalSign Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + Google + globalsigneccrootcar4 DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4 + globalsignr2ca DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2 JDK-8207191: Added T-Systems, GlobalSign and Starfield Services Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + T-Systems + deutschetelekomrootca2 DN: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche Telekom AG, C=DE + ttelesecglobalrootclass3ca DN: CN=T-TeleSec GlobalRoot Class 3, OU=T-Systems Trust Center, O=T-Systems Enterprise Services GmbH, C=DE + ttelesecglobalrootclass2ca DN: CN=T-TeleSec GlobalRoot Class 2, OU=T-Systems Trust Center, O=T-Systems Enterprise Services GmbH, C=DE + Amazon + starfieldservicesrootg2ca DN: CN=Starfield Services Root Certificate Authority - G2, O="Starfield Technologies, Inc.", L=Scottsdale, ST=Arizona, C=US + GlobalSign + globalsignca DN: CN=GlobalSign Root CA, OU=Root CA, O=GlobalSign nv-sa, C=BE + globalsignr3ca DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R3 + globalsigneccrootcar5 DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R5 JDK-8204124: Added GoDaddy Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + GoDaddy + godaddyrootg2ca DN: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2 + godaddyclass2ca DN: C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certification Authority + starfieldclass2ca DN: C=US, O=Starfield Technologies, Inc., OU=Starfield Class 2 Certification Authority + starfieldrootg2ca DN: C=US, ST=Arizona, L=Scottsdale, O=Starfield Technologies, Inc., CN=Starfield Root Certificate Authority - G2 JDK-8204102: Removal of Several Symantec Root CAs The following Symantec root certificates are no longer in use and have been removed: + Symantec + equifaxsecureca DN: OU=Equifax Secure Certificate Authority, O=Equifax, C=US + equifaxsecureglobalebusinessca1 DN: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US + equifaxsecureebusinessca1 DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US + verisignclass1g3ca DN: CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US + verisignclass2g3ca DN: CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US + verisignclass1g2ca DN: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US + verisignclass1ca DN: OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US JDK-8197783: jarsigner Prints When a timestamp Will Expire The `jarsigner` tool now shows more information about the lifetime of a timestamped JAR. New warning and error messages are displayed when a timestamp has expired or is expiring within one year. JDK-8205949: Added Entrust Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + Entrust + entrustrootcaec1 DN: C=US, O=Entrust, Inc., OU=See www.entrust.net/legal-terms, OU=(c) 2012 Entrust, Inc. - for authorized use only, CN=Entrust Root Certification Authority - EC1 + entrust2048ca DN: O=Entrust.net, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Certification Authority (2048) + entrustrootcag2 DN: C=US, O=Entrust, Inc., OU=See www.entrust.net/legal-terms, OU=(c) 2009 Entrust, Inc. - for authorized use only, CN=Entrust Root Certification Authority - G2 + entrustevca DN: C=US, O=Entrust, Inc., OU=www.entrust.net/CPS is incorporated by reference, OU=(c) 2006 Entrust, Inc., CN=Entrust Root Certification Authority + affirmtrustnetworkingca DN: C=US, O=AffirmTrust, CN=AffirmTrust Networking + affirmtrustpremiumca DN: C=US, O=AffirmTrust, CN=AffirmTrust Premium + affirmtrustcommercialca DN: C=US, O=AffirmTrust, CN=AffirmTrust Commercial + affirmtrustpremiumeccca DN: C=US, O=AffirmTrust, CN=AffirmTrust Premium ECC JDK-8229518: Added Support for PKCS#1 v2.2 Algorithms Including RSASSA-PSS Signature The SunRsaSign and SunJCE providers have been enhanced with support for more algorithms defined in PKCS#1 v2.2, such as RSASSA-PSS signature and OAEP using FIPS 180-4 digest algorithms. New constructors and methods have been added to relevant JCA/JCE classes under the `java.security.spec` and `javax.crypto.spec` packages for supporting additional RSASSA-PSS parameters. JDK-8204487: Removal of Baltimore Cybertrust Code Signing CA The following Baltimore CyberTrust Code Signing root certificate is no longer in use and has been removed: + baltimorecodesigningca DN: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE JDK-8207255: Removal of AOL and Swisscom Root Certificates The following root certificates have been removed from the cacerts truststore: + AOL + aolrootca1 DN: CN=America Online Root Certification Authority 1, O=America Online Inc., C=US + aolrootca2 DN: CN=America Online Root Certification Authority 2, O=America Online Inc., C=US + Swisscom + swisscomrootca2 DN: CN=Swisscom Root CA 2, OU=Digital Certificate Services, O=Swisscom, C=ch JDK-8204489: Removal of SECOM Root Certificate The following SECOM root certificate is no longer in use and has been removed: + secomevrootca1 DN: OU=Security Communication EV RootCA1, O="SECOM Trust Systems CO.,LTD.", C=JP JDK-8209512: Added Google Trust Services GlobalSign Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + Google + globalsigneccrootcar4 DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4 + globalsignr2ca DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2 JDK-8207191: Added T-Systems, GlobalSign and Starfield Services Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + T-Systems + deutschetelekomrootca2 DN: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche Telekom AG, C=DE + ttelesecglobalrootclass3ca DN: CN=T-TeleSec GlobalRoot Class 3, OU=T-Systems Trust Center, O=T-Systems Enterprise Services GmbH, C=DE + ttelesecglobalrootclass2ca DN: CN=T-TeleSec GlobalRoot Class 2, OU=T-Systems Trust Center, O=T-Systems Enterprise Services GmbH, C=DE + Amazon + starfieldservicesrootg2ca DN: CN=Starfield Services Root Certificate Authority - G2, O="Starfield Technologies, Inc.", L=Scottsdale, ST=Arizona, C=US + GlobalSign + globalsignca DN: CN=GlobalSign Root CA, OU=Root CA, O=GlobalSign nv-sa, C=BE + globalsignr3ca DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R3 + globalsigneccrootcar5 DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R5 JDK-8204124: Added GoDaddy Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + GoDaddy + godaddyrootg2ca DN: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2 + godaddyclass2ca DN: C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certification Authority + starfieldclass2ca DN: C=US, O=Starfield Technologies, Inc., OU=Starfield Class 2 Certification Authority + starfieldrootg2ca DN: C=US, ST=Arizona, L=Scottsdale, O=Starfield Technologies, Inc., CN=Starfield Root Certificate Authority - G2 JDK-8204102: Removal of Several Symantec Root CAs The following Symantec root certificates are no longer in use and have been removed: + Symantec + equifaxsecureca DN: OU=Equifax Secure Certificate Authority, O=Equifax, C=US + equifaxsecureglobalebusinessca1 DN: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US + equifaxsecureebusinessca1 DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US + verisignclass1g3ca DN: CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US + verisignclass2g3ca DN: CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US + verisignclass1g2ca DN: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US + verisignclass1ca DN: OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US JDK-8197783: jarsigner Prints When a timestamp Will Expire The `jarsigner` tool now shows more information about the lifetime of a timestamped JAR. New warning and error messages are displayed when a timestamp has expired or is expiring within one year. JDK-8205949: Added Entrust Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + Entrust + entrustrootcaec1 DN: C=US, O=Entrust, Inc., OU=See www.entrust.net/legal-terms, OU=(c) 2012 Entrust, Inc. - for authorized use only, CN=Entrust Root Certification Authority - EC1 + entrust2048ca DN: O=Entrust.net, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Certification Authority (2048) + entrustrootcag2 DN: C=US, O=Entrust, Inc., OU=See www.entrust.net/legal-terms, OU=(c) 2009 Entrust, Inc. - for authorized use only, CN=Entrust Root Certification Authority - G2 + entrustevca DN: C=US, O=Entrust, Inc., OU=www.entrust.net/CPS is incorporated by reference, OU=(c) 2006 Entrust, Inc., CN=Entrust Root Certification Authority + affirmtrustnetworkingca DN: C=US, O=AffirmTrust, CN=AffirmTrust Networking + affirmtrustpremiumca DN: C=US, O=AffirmTrust, CN=AffirmTrust Premium + affirmtrustcommercialca DN: C=US, O=AffirmTrust, CN=AffirmTrust Commercial + affirmtrustpremiumeccca DN: C=US, O=AffirmTrust, CN=AffirmTrust Premium ECC JDK-8229518: Added Support for PKCS#1 v2.2 Algorithms Including RSASSA-PSS Signature The SunRsaSign and SunJCE providers have been enhanced with support for more algorithms defined in PKCS#1 v2.2, such as RSASSA-PSS signature and OAEP using FIPS 180-4 digest algorithms. New constructors and methods have been added to relevant JCA/JCE classes under the `java.security.spec` and `javax.crypto.spec` packages for supporting additional RSASSA-PSS parameters. JDK-8204487: Removal of Baltimore Cybertrust Code Signing CA The following Baltimore CyberTrust Code Signing root certificate is no longer in use and has been removed: + baltimorecodesigningca DN: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE JDK-8207255: Removal of AOL and Swisscom Root Certificates The following root certificates have been removed from the cacerts truststore: + AOL + aolrootca1 DN: CN=America Online Root Certification Authority 1, O=America Online Inc., C=US + aolrootca2 DN: CN=America Online Root Certification Authority 2, O=America Online Inc., C=US + Swisscom + swisscomrootca2 DN: CN=Swisscom Root CA 2, OU=Digital Certificate Services, O=Swisscom, C=ch JDK-8204489: Removal of SECOM Root Certificate The following SECOM root certificate is no longer in use and has been removed: + secomevrootca1 DN: OU=Security Communication EV RootCA1, O="SECOM Trust Systems CO.,LTD.", C=JP JDK-8209512: Added Google Trust Services GlobalSign Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + Google + globalsigneccrootcar4 DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4 + globalsignr2ca DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2 JDK-8207191: Added T-Systems, GlobalSign and Starfield Services Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + T-Systems + deutschetelekomrootca2 DN: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche Telekom AG, C=DE + ttelesecglobalrootclass3ca DN: CN=T-TeleSec GlobalRoot Class 3, OU=T-Systems Trust Center, O=T-Systems Enterprise Services GmbH, C=DE + ttelesecglobalrootclass2ca DN: CN=T-TeleSec GlobalRoot Class 2, OU=T-Systems Trust Center, O=T-Systems Enterprise Services GmbH, C=DE + Amazon + starfieldservicesrootg2ca DN: CN=Starfield Services Root Certificate Authority - G2, O="Starfield Technologies, Inc.", L=Scottsdale, ST=Arizona, C=US + GlobalSign + globalsignca DN: CN=GlobalSign Root CA, OU=Root CA, O=GlobalSign nv-sa, C=BE + globalsignr3ca DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R3 + globalsigneccrootcar5 DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R5 JDK-8204124: Added GoDaddy Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + GoDaddy + godaddyrootg2ca DN: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2 + godaddyclass2ca DN: C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certification Authority + starfieldclass2ca DN: C=US, O=Starfield Technologies, Inc., OU=Starfield Class 2 Certification Authority + starfieldrootg2ca DN: C=US, ST=Arizona, L=Scottsdale, O=Starfield Technologies, Inc., CN=Starfield Root Certificate Authority - G2 JDK-8204102: Removal of Several Symantec Root CAs The following Symantec root certificates are no longer in use and have been removed: + Symantec + equifaxsecureca DN: OU=Equifax Secure Certificate Authority, O=Equifax, C=US + equifaxsecureglobalebusinessca1 DN: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US + equifaxsecureebusinessca1 DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US + verisignclass1g3ca DN: CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US + verisignclass2g3ca DN: CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US + verisignclass1g2ca DN: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US + verisignclass1ca DN: OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US JDK-8197783: jarsigner Prints When a timestamp Will Expire The `jarsigner` tool now shows more information about the lifetime of a timestamped JAR. New warning and error messages are displayed when a timestamp has expired or is expiring within one year. JDK-8205949: Added Entrust Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + Entrust + entrustrootcaec1 DN: C=US, O=Entrust, Inc., OU=See www.entrust.net/legal-terms, OU=(c) 2012 Entrust, Inc. - for authorized use only, CN=Entrust Root Certification Authority - EC1 + entrust2048ca DN: O=Entrust.net, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Certification Authority (2048) + entrustrootcag2 DN: C=US, O=Entrust, Inc., OU=See www.entrust.net/legal-terms, OU=(c) 2009 Entrust, Inc. - for authorized use only, CN=Entrust Root Certification Authority - G2 + entrustevca DN: C=US, O=Entrust, Inc., OU=www.entrust.net/CPS is incorporated by reference, OU=(c) 2006 Entrust, Inc., CN=Entrust Root Certification Authority + affirmtrustnetworkingca DN: C=US, O=AffirmTrust, CN=AffirmTrust Networking + affirmtrustpremiumca DN: C=US, O=AffirmTrust, CN=AffirmTrust Premium + affirmtrustcommercialca DN: C=US, O=AffirmTrust, CN=AffirmTrust Commercial + affirmtrustpremiumeccca DN: C=US, O=AffirmTrust, CN=AffirmTrust Premium ECC JDK-8229518: Added Support for PKCS#1 v2.2 Algorithms Including RSASSA-PSS Signature The SunRsaSign and SunJCE providers have been enhanced with support for more algorithms defined in PKCS#1 v2.2, such as RSASSA-PSS signature and OAEP using FIPS 180-4 digest algorithms. New constructors and methods have been added to relevant JCA/JCE classes under the `java.security.spec` and `javax.crypto.spec` packages for supporting additional RSASSA-PSS parameters. JDK-8204487: Removal of Baltimore Cybertrust Code Signing CA The following Baltimore CyberTrust Code Signing root certificate is no longer in use and has been removed: + baltimorecodesigningca DN: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE JDK-8207255: Removal of AOL and Swisscom Root Certificates The following root certificates have been removed from the cacerts truststore: + AOL + aolrootca1 DN: CN=America Online Root Certification Authority 1, O=America Online Inc., C=US + aolrootca2 DN: CN=America Online Root Certification Authority 2, O=America Online Inc., C=US + Swisscom + swisscomrootca2 DN: CN=Swisscom Root CA 2, OU=Digital Certificate Services, O=Swisscom, C=ch JDK-8204489: Removal of SECOM Root Certificate The following SECOM root certificate is no longer in use and has been removed: + secomevrootca1 DN: OU=Security Communication EV RootCA1, O="SECOM Trust Systems CO.,LTD.", C=JP JDK-8209512: Added Google Trust Services GlobalSign Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + Google + globalsigneccrootcar4 DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4 + globalsignr2ca DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2 JDK-8207191: Added T-Systems, GlobalSign and Starfield Services Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + T-Systems + deutschetelekomrootca2 DN: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche Telekom AG, C=DE + ttelesecglobalrootclass3ca DN: CN=T-TeleSec GlobalRoot Class 3, OU=T-Systems Trust Center, O=T-Systems Enterprise Services GmbH, C=DE + ttelesecglobalrootclass2ca DN: CN=T-TeleSec GlobalRoot Class 2, OU=T-Systems Trust Center, O=T-Systems Enterprise Services GmbH, C=DE + Amazon + starfieldservicesrootg2ca DN: CN=Starfield Services Root Certificate Authority - G2, O="Starfield Technologies, Inc.", L=Scottsdale, ST=Arizona, C=US + GlobalSign + globalsignca DN: CN=GlobalSign Root CA, OU=Root CA, O=GlobalSign nv-sa, C=BE + globalsignr3ca DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R3 + globalsigneccrootcar5 DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R5 JDK-8204124: Added GoDaddy Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + GoDaddy + godaddyrootg2ca DN: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2 + godaddyclass2ca DN: C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certification Authority + starfieldclass2ca DN: C=US, O=Starfield Technologies, Inc., OU=Starfield Class 2 Certification Authority + starfieldrootg2ca DN: C=US, ST=Arizona, L=Scottsdale, O=Starfield Technologies, Inc., CN=Starfield Root Certificate Authority - G2 JDK-8204102: Removal of Several Symantec Root CAs The following Symantec root certificates are no longer in use and have been removed: + Symantec + equifaxsecureca DN: OU=Equifax Secure Certificate Authority, O=Equifax, C=US + equifaxsecureglobalebusinessca1 DN: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US + equifaxsecureebusinessca1 DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US + verisignclass1g3ca DN: CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US + verisignclass2g3ca DN: CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US + verisignclass1g2ca DN: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US + verisignclass1ca DN: OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US JDK-8197783: jarsigner Prints When a timestamp Will Expire The `jarsigner` tool now shows more information about the lifetime of a timestamped JAR. New warning and error messages are displayed when a timestamp has expired or is expiring within one year. JDK-8205949: Added Entrust Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + Entrust + entrustrootcaec1 DN: C=US, O=Entrust, Inc., OU=See www.entrust.net/legal-terms, OU=(c) 2012 Entrust, Inc. - for authorized use only, CN=Entrust Root Certification Authority - EC1 + entrust2048ca DN: O=Entrust.net, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Certification Authority (2048) + entrustrootcag2 DN: C=US, O=Entrust, Inc., OU=See www.entrust.net/legal-terms, OU=(c) 2009 Entrust, Inc. - for authorized use only, CN=Entrust Root Certification Authority - G2 + entrustevca DN: C=US, O=Entrust, Inc., OU=www.entrust.net/CPS is incorporated by reference, OU=(c) 2006 Entrust, Inc., CN=Entrust Root Certification Authority + affirmtrustnetworkingca DN: C=US, O=AffirmTrust, CN=AffirmTrust Networking + affirmtrustpremiumca DN: C=US, O=AffirmTrust, CN=AffirmTrust Premium + affirmtrustcommercialca DN: C=US, O=AffirmTrust, CN=AffirmTrust Commercial + affirmtrustpremiumeccca DN: C=US, O=AffirmTrust, CN=AffirmTrust Premium ECC JDK-8229518: Added Support for PKCS#1 v2.2 Algorithms Including RSASSA-PSS Signature The SunRsaSign and SunJCE providers have been enhanced with support for more algorithms defined in PKCS#1 v2.2, such as RSASSA-PSS signature and OAEP using FIPS 180-4 digest algorithms. New constructors and methods have been added to relevant JCA/JCE classes under the `java.security.spec` and `javax.crypto.spec` packages for supporting additional RSASSA-PSS parameters. JDK-8204487: Removal of Baltimore Cybertrust Code Signing CA The following Baltimore CyberTrust Code Signing root certificate is no longer in use and has been removed: + baltimorecodesigningca DN: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE JDK-8207255: Removal of AOL and Swisscom Root Certificates The following root certificates have been removed from the cacerts truststore: + AOL + aolrootca1 DN: CN=America Online Root Certification Authority 1, O=America Online Inc., C=US + aolrootca2 DN: CN=America Online Root Certification Authority 2, O=America Online Inc., C=US + Swisscom + swisscomrootca2 DN: CN=Swisscom Root CA 2, OU=Digital Certificate Services, O=Swisscom, C=ch JDK-8204489: Removal of SECOM Root Certificate The following SECOM root certificate is no longer in use and has been removed: + secomevrootca1 DN: OU=Security Communication EV RootCA1, O="SECOM Trust Systems CO.,LTD.", C=JP JDK-8209512: Added Google Trust Services GlobalSign Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + Google + globalsigneccrootcar4 DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4 + globalsignr2ca DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2 JDK-8207191: Added T-Systems, GlobalSign and Starfield Services Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + T-Systems + deutschetelekomrootca2 DN: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche Telekom AG, C=DE + ttelesecglobalrootclass3ca DN: CN=T-TeleSec GlobalRoot Class 3, OU=T-Systems Trust Center, O=T-Systems Enterprise Services GmbH, C=DE + ttelesecglobalrootclass2ca DN: CN=T-TeleSec GlobalRoot Class 2, OU=T-Systems Trust Center, O=T-Systems Enterprise Services GmbH, C=DE + Amazon + starfieldservicesrootg2ca DN: CN=Starfield Services Root Certificate Authority - G2, O="Starfield Technologies, Inc.", L=Scottsdale, ST=Arizona, C=US + GlobalSign + globalsignca DN: CN=GlobalSign Root CA, OU=Root CA, O=GlobalSign nv-sa, C=BE + globalsignr3ca DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R3 + globalsigneccrootcar5 DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R5 JDK-8204124: Added GoDaddy Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + GoDaddy + godaddyrootg2ca DN: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2 + godaddyclass2ca DN: C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certification Authority + starfieldclass2ca DN: C=US, O=Starfield Technologies, Inc., OU=Starfield Class 2 Certification Authority + starfieldrootg2ca DN: C=US, ST=Arizona, L=Scottsdale, O=Starfield Technologies, Inc., CN=Starfield Root Certificate Authority - G2 JDK-8204102: Removal of Several Symantec Root CAs The following Symantec root certificates are no longer in use and have been removed: + Symantec + equifaxsecureca DN: OU=Equifax Secure Certificate Authority, O=Equifax, C=US + equifaxsecureglobalebusinessca1 DN: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US + equifaxsecureebusinessca1 DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US + verisignclass1g3ca DN: CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US + verisignclass2g3ca DN: CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US + verisignclass1g2ca DN: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US + verisignclass1ca DN: OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US JDK-8197783: jarsigner Prints When a timestamp Will Expire The `jarsigner` tool now shows more information about the lifetime of a timestamped JAR. New warning and error messages are displayed when a timestamp has expired or is expiring within one year. JDK-8205949: Added Entrust Root Certificates The following root certificates have been added to the OpenJDK cacerts truststore: + Entrust + entrustrootcaec1 DN: C=US, O=Entrust, Inc., OU=See www.entrust.net/legal-terms, OU=(c) 2012 Entrust, Inc. - for authorized use only, CN=Entrust Root Certification Authority - EC1 + entrust2048ca DN: O=Entrust.net, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Certification Authority (2048) + entrustrootcag2 DN: C=US, O=Entrust, Inc., OU=See www.entrust.net/legal-terms, OU=(c) 2009 Entrust, Inc. - for authorized use only, CN=Entrust Root Certification Authority - G2 + entrustevca DN: C=US, O=Entrust, Inc., OU=www.entrust.net/CPS is incorporated by reference, OU=(c) 2006 Entrust, Inc., CN=Entrust Root Certification Authority + affirmtrustnetworkingca DN: C=US, O=AffirmTrust, CN=AffirmTrust Networking + affirmtrustpremiumca DN: C=US, O=AffirmTrust, CN=AffirmTrust Premium + affirmtrustcommercialca DN: C=US, O=AffirmTrust, CN=AffirmTrust Commercial + affirmtrustpremiumeccca DN: C=US, O=AffirmTrust, CN=AffirmTrust Premium ECC JDK-8229518: Added Support for PKCS#1 v2.2 Algorithms Including RSASSA-PSS Signature The SunRsaSign and SunJCE providers have been enhanced with support for more algorithms defined in PKCS#1 v2.2, such as RSASSA-PSS signature and OAEP using FIPS 180-4 digest algorithms. New constructors and methods have been added to relevant JCA/JCE classes under the `java.security.spec` and `javax.crypto.spec` packages for supporting additional RSASSA-PSS parameters. JDK-8204487: Removal of Baltimore Cybertrust Code Signing CA The following Baltimore CyberTrust Code Signing root certificate is no longer in use and has been removed: + baltimorecodesigningca DN: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE JDK-8207255: Removal of AOL and Swisscom Root Certificates The following root certificates have been removed from the cacerts truststore: + AOL + aolrootca1 DN: CN=America Online Root Certification Authority 1, O=America Online Inc., C=US + aolrootca2 DN: CN=America Online Root Certification Authority 2, O=America Online Inc., C=US + Swisscom + swisscomrootca2 DN: CN=Swisscom Root CA 2, OU=Digital Certificate Services, O=Swisscom, C=ch JDK-8204489: Removal of SECOM Root Certificate The following SECOM root certificate is no longer in use and has been removed: + secomevrootca1 DN: OU=Security Communication EV RootCA1, O="SECOM Trust Systems CO.,LTD.", C=JP core-libs/java.util.concurrent: JDK-8196867: ThreadPoolExecutor Should Not Specify a Dependency on Finalization Previous versions of ThreadPoolExecutor had a finalize method that shut down the thread pool, but in this version the finalize method does nothing. This should have no visible effect unless a subclass explicitly invokes the finalize method and relies on the executor being shutdown. security-libs/org.ietf.jgss:krb5: JDK-8202681: Kerberos Sequence Number Issues Previously, when mutual authentication was not requested by the Kerberos 5 initiator, there was no mechanism to negotiate the acceptor's initial sequence number. With this release, if the system property `sun.security.krb5.acceptor.sequence.number.nonmutual` is set to `initiator`, the SunJGSS provider will use the initiator's initial sequence number as the acceptor's initial sequence number. If set to `zero` or `0`, 0 is used. The default value is `initiator`. All other values are illegal and will throw an Error when the system property is read. JDK-8201351: KerberosString Uses UTF-8 Encoding by Default The `KerberosString` ASN.1 type now uses the UTF-8 encoding by default. A `KerberosString` can be used to encode principal names, realm names, and other text-based fields. Set the system property `sun.security.krb5.msinterop.kstring` to `false` to encode `KerberosString` as ASCII. JDK-8193850: Support for AES Encryption with HMAC-SHA2 for Kerberos 5 Defined in RFC 8009 The Kerberos 5 encryption types of `aes128-cts-hmac-sha256-128` and `aes256-cts-hmac-sha384-192` defined in RFC 8009 are supported. These encryption types are enabled by default. The default order of preference is "`aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128 des3-cbc-sha1 arcfour-hmac-md5 des-cbc-crc des-cbc-md5`." Users can use the `default_tkt_enctypes` and `default_tgs_enctypes` settings in the `krb5.conf` file to modify the list. JDK-8202681: Kerberos Sequence Number Issues Previously, when mutual authentication was not requested by the Kerberos 5 initiator, there was no mechanism to negotiate the acceptor's initial sequence number. With this release, if the system property `sun.security.krb5.acceptor.sequence.number.nonmutual` is set to `initiator`, the SunJGSS provider will use the initiator's initial sequence number as the acceptor's initial sequence number. If set to `zero` or `0`, 0 is used. The default value is `initiator`. All other values are illegal and will throw an Error when the system property is read. JDK-8201351: KerberosString Uses UTF-8 Encoding by Default The `KerberosString` ASN.1 type now uses the UTF-8 encoding by default. A `KerberosString` can be used to encode principal names, realm names, and other text-based fields. Set the system property `sun.security.krb5.msinterop.kstring` to `false` to encode `KerberosString` as ASCII. JDK-8193850: Support for AES Encryption with HMAC-SHA2 for Kerberos 5 Defined in RFC 8009 The Kerberos 5 encryption types of `aes128-cts-hmac-sha256-128` and `aes256-cts-hmac-sha384-192` defined in RFC 8009 are supported. These encryption types are enabled by default. The default order of preference is "`aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128 des3-cbc-sha1 arcfour-hmac-md5 des-cbc-crc des-cbc-md5`." Users can use the `default_tkt_enctypes` and `default_tgs_enctypes` settings in the `krb5.conf` file to modify the list. JDK-8202681: Kerberos Sequence Number Issues Previously, when mutual authentication was not requested by the Kerberos 5 initiator, there was no mechanism to negotiate the acceptor's initial sequence number. With this release, if the system property `sun.security.krb5.acceptor.sequence.number.nonmutual` is set to `initiator`, the SunJGSS provider will use the initiator's initial sequence number as the acceptor's initial sequence number. If set to `zero` or `0`, 0 is used. The default value is `initiator`. All other values are illegal and will throw an Error when the system property is read. JDK-8201351: KerberosString Uses UTF-8 Encoding by Default The `KerberosString` ASN.1 type now uses the UTF-8 encoding by default. A `KerberosString` can be used to encode principal names, realm names, and other text-based fields. Set the system property `sun.security.krb5.msinterop.kstring` to `false` to encode `KerberosString` as ASCII. JDK-8193850: Support for AES Encryption with HMAC-SHA2 for Kerberos 5 Defined in RFC 8009 The Kerberos 5 encryption types of `aes128-cts-hmac-sha256-128` and `aes256-cts-hmac-sha384-192` defined in RFC 8009 are supported. These encryption types are enabled by default. The default order of preference is "`aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128 des3-cbc-sha1 arcfour-hmac-md5 des-cbc-crc des-cbc-md5`." Users can use the `default_tkt_enctypes` and `default_tgs_enctypes` settings in the `krb5.conf` file to modify the list. tools: JDK-8202512: JEP 323: Local-Variable Syntax for Lambda Parameters The reserved type name `var` can now be used when declaring the formal parameters of a lambda expression ([JEP 323](http://openjdk.java.net/jeps/323)). This builds on the ability in Java SE 10 to use `var` when declaring local variables. Using `var` for a formal parameter of a lambda expression causes the type of the parameter to be inferred, using the same rules as when neither `var` nor an explicit type is present. Lambda expressions have allowed their formal parameters to be declared without explicit types since Java SE 8. If `var` is used for any formal parameter of a lambda expression, then it must be used for all formal parameters of that lambda expression. JDK-8205402: JEP 336: Deprecate the Pack200 Tools and API Deprecate the `pack200` and `unpack200` tools, and the Pack200 API in `java.util.jar` ([JEP 336](http://openjdk.java.net/jeps/336)). The `pack200` API and the tools associated with it, `pack200` and `unpack200`, have been deprecated and will be removed in a future release. Those tools are still included in JDK 11, but will no longer be updated to support the latest class file format. Class files with unknown attributes will be passed-through without compression. JDK-8202512: JEP 323: Local-Variable Syntax for Lambda Parameters The reserved type name `var` can now be used when declaring the formal parameters of a lambda expression ([JEP 323](http://openjdk.java.net/jeps/323)). This builds on the ability in Java SE 10 to use `var` when declaring local variables. Using `var` for a formal parameter of a lambda expression causes the type of the parameter to be inferred, using the same rules as when neither `var` nor an explicit type is present. Lambda expressions have allowed their formal parameters to be declared without explicit types since Java SE 8. If `var` is used for any formal parameter of a lambda expression, then it must be used for all formal parameters of that lambda expression. JDK-8205402: JEP 336: Deprecate the Pack200 Tools and API Deprecate the `pack200` and `unpack200` tools, and the Pack200 API in `java.util.jar` ([JEP 336](http://openjdk.java.net/jeps/336)). The `pack200` API and the tools associated with it, `pack200` and `unpack200`, have been deprecated and will be removed in a future release. Those tools are still included in JDK 11, but will no longer be updated to support the latest class file format. Class files with unknown attributes will be passed-through without compression. core-libs/java.lang.invoke: JDK-8201497: filterArguments Runs Multiple Filters in the Wrong Order The specification of the method `java.lang.invoke.MethodHandles.filterArguments` was clarified to state more clearly that filter arguments are invoked in left to right order. The implementation of this method was also fixed to ensure that it conformed to the specification. Prior to the fix, the implementation incorrectly invoked filters in right to left order. For the majority of usages, it is expected that the change in behavior will not be observable. Only in a minority of cases, where two or more filters have side-effects that affect their results, will the change in behavior be observable. security-libs/javax.xml.crypto: JDK-8202891: Updated xmldsig Implementation to Apache Santuario 2.1.1 The XMLDSig provider implementation in the `java.xml.crypto` module has been updated to version 2.1.1 of Apache Santuario. New features include: 1. Support for the SHA-224 and SHA-3 DigestMethod algorithms specified in RFC 6931. 2. Support for the HMAC-SHA224, RSA-SHA224, ECDSA-SHA224, and RSASSA-PSS family of SignatureMethod algorithms specified in RFC 6931. other-libs/other: JDK-8199466: javax.transaction.xa Package Moved to the java.transaction.xa Module The maintenance JSR for the Java Transaction (JSR 907) has dropped package `javax.transaction.xa` from the API to allow it be subsumed by Java SE. As part of this effort, package `javax.transaction.xa` has been moved from module `java.sql` to a new module `java.transaction.xa`. The following types continue to be part of the `javax.transaction.xa` package: - `javax.transaction.xa.XAResource` - `javax.transaction.xa.Xid` - `javax.transaction.xa.XAException` The change should be transparent to existing applications on the class path or module path. core-libs/javax.lang.model: JDK-8199398: Missing Types Are Consistently Modeled as ERROR Types Missing types are now consistently modeled as ERROR types, and the `javac` internal exception, `CompletionFailure`, is no longer thrown to API clients. Previously, annotation processors and other `javax.lang.model` clients could, in some cases, observe missing types modeled as DECLARED types with a `javac` internal exception, `CompletionFailure`, thrown out of the model methods when manipulating such types. core-libs: JDK-8202999: Removal of sun.misc.Unsafe.defineClass The `sun.misc.Unsafe.defineClass` class has been removed. Users should use the public replacement, `java.lang.invoke.MethodHandles.Lookup.defineClass`, added in Java SE 9. For more details see the Java documentation: [https://docs.oracle.com/javase/9/docs/api/java/lang/invoke/MethodHandles.Lookup.html#defineClass-byte:A-](https://docs.oracle.com/javase/9/docs/api/java/lang/invoke/MethodHandles.Lookup.html#defineClass-byte:A-) core-libs/jdk.nashorn: JDK-8205932: JEP 335: Deprecate the Nashorn JavaScript Engine Deprecate the Nashorn JavaScript script engine and APIs, and the jjs tool, with the intent to remove them in a future release ([JEP 335](http://openjdk.java.net/jeps/335)). The Nashorn JavaScript Engine implementation, the APIs and the `jjs` shell tool have been deprecated and might be removed in a future release. Code that uses classes and interfaces from `jdk.nashorn.api.scripting` and `jdk.nashorn.api.tree` packages will get a deprecation warning from `javac`. The Nashorn engine (when used by `javax.script` API or `jrunscript` tool) as well as `jjs` shell tool will print a warning message about deprecation. To disable this runtime warning message, users can include the new Nashorn option, `--no-deprecation-warning`. This might be useful for compatibility scripts that depend on exact output (such as, to avoid the warning breaking their expected exact output). JDK-8236933: JEP 372: Remove the Nashorn JavaScript Engine Summary ------- Remove the Nashorn JavaScript script engine and APIs, and the `jjs` tool. The engine, the APIs, and the tool were [deprecated for removal in Java 11](http://openjdk.java.net/jeps/335) with the express intent to remove them in a future release. Motivation ---------- The Nashorn JavaScript engine was first incorporated into JDK 8 via [JEP 174](http://openjdk.java.net/jeps/174) as a replacement for the Rhino scripting engine. When it was released, it was a complete implementation of the ECMAScript-262 5.1 standard. With the rapid pace at which ECMAScript language constructs, along with APIs, are adapted and modified, we have found Nashorn challenging to maintain. Non-Goals --------- This removal does not affect, in any way, the `javax.script` API. Description ----------- Two [JDK modules](http://openjdk.java.net/jeps/200#Design-principles) will be permanently removed: - `jdk.scripting.nashorn` -- contains the `jdk.nashorn.api.scripting` and `jdk.nashorn.api.tree` packages. - `jdk.scripting.nashorn.shell` -- contains the `jjs` tool. Risks and Assumptions --------------------- We assume that developers who rely on Nashorn have had enough notice of its proposed removal to make alternative arrangements. The deprecation-for-removal of Nashorn in JDK 11 was confirmed in June 2018, causing the proposed removal to be flagged at every use of the `jdk.nashorn.*` API and the `jjs` tool in JDK 11, 12, and 13. During this period, no set of credible developers expressed a clear desire to maintain Nashorn in JDK 14 and beyond. hotspot/compiler: JDK-8201189: Lazy Allocation of Compiler Threads A new command line flag ` -XX:+UseDynamicNumberOfCompilerThreads` has been added to dynamically control compiler threads. In tiered compilation mode, which is on by default, the VM starts a large number of compiler threads on systems with many CPUs regardless of the available memory and the number of compilation requests. Because the threads consume memory even when they are idle (which is almost all of the time), this leads to an inefficient use of resources. To address this issue, the implementation has been changed to start only one compiler thread of each type during startup and to handle the start and shutdown of further threads dynamically. It is controlled by a new command line flag, which is on by default: `-XX:+UseDynamicNumberOfCompilerThreads` JDK-8199847: Deprecate -XX:+AggressiveOpts The VM option `-XX:+AggressiveOpts` is deprecated in JDK 11 and will be removed in a future release. The option was originally supposed to enable experimental optimizations of the C2 compiler to improve performance of specific benchmarks. Most features have been removed or integrated over time leaving the behavior of the option ill-defined and error-prone. The only effect that the flag currently has is setting `AutoBoxCacheMax` to 20000 and `BiasedLockingStartupDelay` to 500. The same configuration can be achieved by setting their corresponding flags from the command line. Therefore, `-XX:+AggressiveOpts` will no longer be available in a future release. JDK-8201189: Lazy Allocation of Compiler Threads A new command line flag ` -XX:+UseDynamicNumberOfCompilerThreads` has been added to dynamically control compiler threads. In tiered compilation mode, which is on by default, the VM starts a large number of compiler threads on systems with many CPUs regardless of the available memory and the number of compilation requests. Because the threads consume memory even when they are idle (which is almost all of the time), this leads to an inefficient use of resources. To address this issue, the implementation has been changed to start only one compiler thread of each type during startup and to handle the start and shutdown of further threads dynamically. It is controlled by a new command line flag, which is on by default: `-XX:+UseDynamicNumberOfCompilerThreads` JDK-8199847: Deprecate -XX:+AggressiveOpts The VM option `-XX:+AggressiveOpts` is deprecated in JDK 11 and will be removed in a future release. The option was originally supposed to enable experimental optimizations of the C2 compiler to improve performance of specific benchmarks. Most features have been removed or integrated over time leaving the behavior of the option ill-defined and error-prone. The only effect that the flag currently has is setting `AutoBoxCacheMax` to 20000 and `BiasedLockingStartupDelay` to 500. The same configuration can be achieved by setting their corresponding flags from the command line. Therefore, `-XX:+AggressiveOpts` will no longer be available in a future release. security-libs/javax.net.ssl: JDK-8245485: JEP 332: Transport Layer Security (TLS) 1.3 JDK 8u261 includes an implementation of the Transport Layer Security (TLS) 1.3 specification (RFC 8446). For more details including a list of the features that are supported, refer to the *Java Secure Socket Extension (JSSE) Reference Guide* documentation and [JEP 332](http://openjdk.java.net/jeps/332). For TLS 1.3, the following new standard algorithm names are defined: 1. TLS protocol version name: TLSv1.3 2. `SSLContext` algorithm name: TLSv1.3 3. TLS cipher suite names for TLS 1.3: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 TLS 1.3 is *disabled* for default SSLContext("SSL" or "TLS") for *client end-point*. The TLS 1.3 protocol can be enabled using several mechanisms already available in the JDK. For example, TLS 1.3 protocol can be enabled on SSL/TLS connections using SSLSocket/SSLEngine/SSLServerSocket APIs and system properties by the following: 1) `sslSocket.setEnabledProtocols(new String[] { "TLSv1.3", "TLSv1.2"});` 2) Setting up and using a TLSv1.3 based SSLContext : `SSLContext ctx = SSLContext.getInstance("TLSv1.3");` 3) Using the SSLParameters API: `sslParameters.setProtocols(new String[] {"TLSv1.3", "TLSv1.2"});` 4) The `jdk.tls.client.protocols` system property can also be used to control the protocols in use for a TLS connection. One may launch their application with this property. For example, `java -Djdk.tls.client.protocols="TLSv1.3,TLSv1.2"` enables TLSv1.3 and TLSv1.2 on client SSLSockets. 5) The `https.protocols` system property can also be used to control the protocols on connection obtained through use of the `HttpsURLConnection` class or `URL.openStream()` operations. For example, `-Dhttps.protocols=TLSv1.3,TLSv1.2`. A new system property, `jdk.tls.server.protocols`, has been added to configure the default enabled protocol suite in the server side of the SunJSSE provider. A new security property, `jdk.tls.keyLimits`, has been added for TLS 1.3. When the specified amount of data of a specific algorithm has been processed, a post-handshake Key and IV Update is triggered to derive new keys. Note that TLS 1.3 is not directly compatible with previous versions. Although TLS 1.3 can be implemented with a backward-compatibility mode, there are still several compatibility risks to take into account when upgrading to TLS 1.3: 1. TLS 1.3 uses a half-close policy, while TLS 1.2 and prior versions use a duplex-close policy. For applications that depend on the duplex-close policy, there might be compatibility issues when upgrading to TLS 1.3. A new system property, `jdk.tls.acknowledgeCloseNotify`, is added. The default value of the system property is "false". If the system property is set to "true", a corresponding `close_notify` alert will be sent when receiving a `close_notify` alert, and the connection will be duplex closed. 2. The `signature_algorithms_cert` extension requires that pre-defined signature algorithms are used for certificate authentication. In practice, however, an application can use unsupported signature algorithms. 3. The DSA signature algorithm is not supported in TLS 1.3. If a server is configured to only use DSA certificates, it cannot upgrade to TLS 1.3. 4. The supported cipher suites for TLS 1.3 are not the same as TLS 1.2 and prior versions. If an application hard-codes cipher suites that are no longer supported, it cannot use TLS 1.3 without modifying the application code. 5. The TLS 1.3 session resumption and key update behaviors are different from TLS 1.2 and prior versions. The compatibility impact should be minimal; however, there could be a risk if an application depends on the handshake details of the TLS protocols. 6. The legacy `com.sun.net.ssl.dhKeyExchangeFix` system property has been removed from the new TLS implementation. Improved JSSE debug logging format has been introduced to record the logger name, the logger level, the thread ID, the thread name, the time and the caller for each log item. Use the `javax.net.debug=all` system property to get full debug logs. JDK-8206170: JEP 332: Transport Layer Security (TLS) 1.3 The JDK 11 release includes an implementation of the Transport Layer Security (TLS) 1.3 specification (RFC 8446). For more details including a list of the features that are supported, refer to the *Java Secure Socket Extension (JSSE) Reference Guide* documentation and [JEP 332](http://openjdk.java.net/jeps/332). For TLS 1.3, the following new standard algorithm names are defined: 1. TLS protocol version name: TLSv1.3 2. SSLContext algorithm name: TLSv1.3 3. TLS cipher suite names for TLS 1.3: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 4. keyType for X509KeyManager: RSASSA-PSS 5. authType for X509TrustManager: RSASSA-PSS A new Security Property, `jdk.tls.keyLimits`, has been added for TLS 1.3. When the specified amount of data of a specific algorithm has been processed, a post-handshake Key and IV Update is triggered to derive new keys. A new System Property, `jdk.tls.server.protocols`, has been added to configure the default enabled protocol suite in server side of SunJSSE provider. Note that the KRB5 cipher suites implementation has been removed from the JDK because they are no longer considered safe to use. Note that TLS 1.3 is not directly compatible with previous versions. Although TLS 1.3 can be implemented with a backward-compatibility mode, there are still several compatibility risks to take into account when upgrading to TLS 1.3: 1. TLS 1.3 uses a half-close policy, while TLS 1.2 and prior versions use a duplex-close policy. For applications that depend on the duplex-close policy, there may be compatibility issues when upgrading to TLS 1.3. 2. The signature_algorithms_cert extension requires that pre-defined signature algorithms are used for certificate authentication. In practice, however, an application may use unsupported signature algorithms. 3. The DSA signature algorithm is not supported in TLS 1.3. If a server is configured to only use DSA certificates, it cannot upgrade to TLS 1.3. 4. The supported cipher suites for TLS 1.3 are not the same as TLS 1.2 and prior versions. If an application hard-codes cipher suites which are no longer supported, it may not be able to use TLS 1.3 without modifying the application code. 5. The TLS 1.3 session resumption and key update behaviors are different from TLS 1.2 and prior versions. The compatibility impact should be minimal, but it could be a risk if an application depends on the handshake details of the TLS protocols. The System properties, `jdk.tls.client.protocols` and `jdk.tls.server.protocols`, can be used to configure the default enabled protocols accordingly in the SunJSSE provider if needed. security-libs/javax.crypto: JDK-8208580: Added Brainpool EC Support (RFC 5639) The SunEC provider has been enhanced to support 4 additional Brainpool curves as defined in RFC 5639, *Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation*. The corresponding EC domain parameters can be created by using `java.security.spec.ECGenParameterSpec` objects with standard names of brainpoolP256r1, brainpoolP320r1, brainpoolP384r1, and brainpoolP512r1. Note that the SunJSSE provider has not yet been enhanced to support these brainpool curves. JDK-8210795: JEP 329: ChaCha20 and Poly1305 Cryptographic Algorithms Implement the ChaCha20 and ChaCha20-Poly1305 ciphers as specified in RFC 7539. ChaCha20 is a newer stream cipher that can replace the older, insecure RC4 stream cipher. Those wishing to obtain an instance of the ChaCha20 stream cipher may use the algorithm string "ChaCha20" with the `Cipher.getInstance` method. Those wishing to use ChaCha20 in AEAD mode with the Poly1305 authenticator may use the algorithm string "ChaCha20-Poly1305". See the "Java Security Standard Algorithm Names" document for more details. JDK-8210684: JEP 324: Key Agreement with Curve25519 and Curve448 [JEP 324](http://openjdk.java.net/jeps/324) adds an implementation of a new key agreement scheme using Curve25519 and Curve448 as described in RFC 7748. This implementation is available as a Java Cryptography Architecture service, but it has not been incorporated into the new TLS 1.3 implementation. JDK-8205471: RSASSA-PSS Signature Support Added to SunMSCAPI The RSASSA-PSS signature algorithm support has been added to the SunMSCAPI provider. JDK-8208580: Added Brainpool EC Support (RFC 5639) The SunEC provider has been enhanced to support 4 additional Brainpool curves as defined in RFC 5639, *Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation*. The corresponding EC domain parameters can be created by using `java.security.spec.ECGenParameterSpec` objects with standard names of brainpoolP256r1, brainpoolP320r1, brainpoolP384r1, and brainpoolP512r1. Note that the SunJSSE provider has not yet been enhanced to support these brainpool curves. JDK-8210795: JEP 329: ChaCha20 and Poly1305 Cryptographic Algorithms Implement the ChaCha20 and ChaCha20-Poly1305 ciphers as specified in RFC 7539. ChaCha20 is a newer stream cipher that can replace the older, insecure RC4 stream cipher. Those wishing to obtain an instance of the ChaCha20 stream cipher may use the algorithm string "ChaCha20" with the `Cipher.getInstance` method. Those wishing to use ChaCha20 in AEAD mode with the Poly1305 authenticator may use the algorithm string "ChaCha20-Poly1305". See the "Java Security Standard Algorithm Names" document for more details. JDK-8210684: JEP 324: Key Agreement with Curve25519 and Curve448 [JEP 324](http://openjdk.java.net/jeps/324) adds an implementation of a new key agreement scheme using Curve25519 and Curve448 as described in RFC 7748. This implementation is available as a Java Cryptography Architecture service, but it has not been incorporated into the new TLS 1.3 implementation. JDK-8205471: RSASSA-PSS Signature Support Added to SunMSCAPI The RSASSA-PSS signature algorithm support has been added to the SunMSCAPI provider. JDK-8208580: Added Brainpool EC Support (RFC 5639) The SunEC provider has been enhanced to support 4 additional Brainpool curves as defined in RFC 5639, *Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation*. The corresponding EC domain parameters can be created by using `java.security.spec.ECGenParameterSpec` objects with standard names of brainpoolP256r1, brainpoolP320r1, brainpoolP384r1, and brainpoolP512r1. Note that the SunJSSE provider has not yet been enhanced to support these brainpool curves. JDK-8210795: JEP 329: ChaCha20 and Poly1305 Cryptographic Algorithms Implement the ChaCha20 and ChaCha20-Poly1305 ciphers as specified in RFC 7539. ChaCha20 is a newer stream cipher that can replace the older, insecure RC4 stream cipher. Those wishing to obtain an instance of the ChaCha20 stream cipher may use the algorithm string "ChaCha20" with the `Cipher.getInstance` method. Those wishing to use ChaCha20 in AEAD mode with the Poly1305 authenticator may use the algorithm string "ChaCha20-Poly1305". See the "Java Security Standard Algorithm Names" document for more details. JDK-8210684: JEP 324: Key Agreement with Curve25519 and Curve448 [JEP 324](http://openjdk.java.net/jeps/324) adds an implementation of a new key agreement scheme using Curve25519 and Curve448 as described in RFC 7748. This implementation is available as a Java Cryptography Architecture service, but it has not been incorporated into the new TLS 1.3 implementation. JDK-8205471: RSASSA-PSS Signature Support Added to SunMSCAPI The RSASSA-PSS signature algorithm support has been added to the SunMSCAPI provider. JDK-8208580: Added Brainpool EC Support (RFC 5639) The SunEC provider has been enhanced to support 4 additional Brainpool curves as defined in RFC 5639, *Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation*. The corresponding EC domain parameters can be created by using `java.security.spec.ECGenParameterSpec` objects with standard names of brainpoolP256r1, brainpoolP320r1, brainpoolP384r1, and brainpoolP512r1. Note that the SunJSSE provider has not yet been enhanced to support these brainpool curves. JDK-8210795: JEP 329: ChaCha20 and Poly1305 Cryptographic Algorithms Implement the ChaCha20 and ChaCha20-Poly1305 ciphers as specified in RFC 7539. ChaCha20 is a newer stream cipher that can replace the older, insecure RC4 stream cipher. Those wishing to obtain an instance of the ChaCha20 stream cipher may use the algorithm string "ChaCha20" with the `Cipher.getInstance` method. Those wishing to use ChaCha20 in AEAD mode with the Poly1305 authenticator may use the algorithm string "ChaCha20-Poly1305". See the "Java Security Standard Algorithm Names" document for more details. JDK-8210684: JEP 324: Key Agreement with Curve25519 and Curve448 [JEP 324](http://openjdk.java.net/jeps/324) adds an implementation of a new key agreement scheme using Curve25519 and Curve448 as described in RFC 7748. This implementation is available as a Java Cryptography Architecture service, but it has not been incorporated into the new TLS 1.3 implementation. JDK-8205471: RSASSA-PSS Signature Support Added to SunMSCAPI The RSASSA-PSS signature algorithm support has been added to the SunMSCAPI provider. core-libs/java.nio: JDK-8201496: SelectableChannel.register Can Be Invoked While a Selection Operation Is in Progress `java.nio.channels.Selector` historically specified its key set (the set containing the keys representing the channels registered with the selector) to not be thread safe. Selection operations were specified to synchronize on this key set. Additionally, the `register` methods defined by `java.nio.channels.SelectableChannel` (`SocketChannel`, `ServerSocketChannel`, ...) were also specified to synchronize on the selector's key set and therefore block if invoked concurrently with another registration or selection operation. The specification has changed in Java SE 11 so that the selector's key set is specified to be safe for use by concurrent threads. Selection operations are no longer specified to synchronize on the key set. This allows threads to register channels while a selection operation is in progress; the new registration takes effect at the next selection operation. `SelectionKey` `interestOps(int)` has also been re-specified so that it can be called at any time. If invoked while a selection operation is in progress, then it has no effect upon that operation; the change to the key's interest set will be seen by the next selection operation. Code that synchronizes on the `Selector`'s selected-key set is not impacted by this change as selection operations continue to be specified to synchronize on the selected-key set. The `Selector` API is pluggable. `SelectorProvider` implementations that exist outside of the JDK will need to be updated to align their `Selector` implementation with the updated specification. JDK-8201169: Readiness Information Previously Recorded in SelectionKey Ready Set Not Preserved The `java.nio.channels.Selector` API specifies precisely how selection operations add selection keys to the selector's selected-key set or update the readiness information of selection keys already in the set. The `Selector` implementations in the JDK did not historically implement the latter correctly, meaning that the readiness information was overridden and previous readiness information was not preserved for cases where a channel is selected and its key was already in the selected-key set. This issue has been fixed in JDK 11. This behavior change may surprise code that invokes `select` (or `selectNow`) and doesn't process keys added to the selected-key set before performing another selection operation. JDK-8197957: Removal of sun.nio.ch.disableSystemWideOverlappingFileLockCheck Property The property `sun.nio.ch.disableSystemWideOverlappingFileLockCheck` has been removed. Consequently, compatibility with the older locking approach has also been removed. JDK 6 introduced the system property `sun.nio.ch.disableSystemWideOverlappingFileLockCheck` to control file locking behavior. Specifically, the property was used to enable suppression of JVM-wide file locking and provide compatibility with JDK 1.4 and JDK 5. The old behavior was constrained to check for locks obtained only on the channel instance and not JVM-wide, which is what was actually specified. JDK-8200089: DatagramChannel.send Throws AlreadyConnectedException Instead of IllegalArgumentException Prior to JDK 11, invoking `DatagramChannel.send(ByteBuffer,SocketAddress)` on a `DatagramChannel` connected to an address different from the address specified to the method caused an unspecified `IllegalArgumentException` to be thrown. In Java SE 11, the specification has been clarified to specify `java.nio.channels.AlreadyConnectedException` for this case, and the implementation has been changed to throw the correct exception. JDK-8198692: Separate Blocking and Non-blocking Code Paths The implementations of `SocketChannel`, `ServerSocketChannel`, `DatagramChannel`, `Pipe.SourceChannel` and `Pipe.SinkChannel` have been refactored in JDK 11 to separate the code paths for blocking and non-blocking I/O. This improves performance and also improves reliability for cases where a channel is asynchronously closed or threads doing I/O operations are interrupted. The refactoring results the following behavioral changes: 1. Closing a connected `SocketChannel` that is registered with a `Selector` will now consistently delay closing the underlying connection until the closed channel is flushed from all selectors that it is registered with. Similarly, closing a `ServerSocketChannel` that is registered with `Selector` will now consistently delay closing the underlying listener socket until it is flushed from all selectors that it is registered with. The behavior varied by platform in previous releases. Developers using tools such as `netstat` to monitor network connection should be aware of this change, particularly with libraries or applications that do not perform selection operations in a timely manner to flush closed channels from selectors. 2. Invoking an I/O operation on a selectable channel configured non-blocking and with the interrupt status set no longer closes the channel. 3. Invoking `configureBlocking(false)` on a selectable channel will now block until outstanding blocking I/O operations have completed. The specification has always allowed this but the implementation in the JDK didn't historically wait until blocking I/O operations in progress completed. JDK-8201496: SelectableChannel.register Can Be Invoked While a Selection Operation Is in Progress `java.nio.channels.Selector` historically specified its key set (the set containing the keys representing the channels registered with the selector) to not be thread safe. Selection operations were specified to synchronize on this key set. Additionally, the `register` methods defined by `java.nio.channels.SelectableChannel` (`SocketChannel`, `ServerSocketChannel`, ...) were also specified to synchronize on the selector's key set and therefore block if invoked concurrently with another registration or selection operation. The specification has changed in Java SE 11 so that the selector's key set is specified to be safe for use by concurrent threads. Selection operations are no longer specified to synchronize on the key set. This allows threads to register channels while a selection operation is in progress; the new registration takes effect at the next selection operation. `SelectionKey` `interestOps(int)` has also been re-specified so that it can be called at any time. If invoked while a selection operation is in progress, then it has no effect upon that operation; the change to the key's interest set will be seen by the next selection operation. Code that synchronizes on the `Selector`'s selected-key set is not impacted by this change as selection operations continue to be specified to synchronize on the selected-key set. The `Selector` API is pluggable. `SelectorProvider` implementations that exist outside of the JDK will need to be updated to align their `Selector` implementation with the updated specification. JDK-8201169: Readiness Information Previously Recorded in SelectionKey Ready Set Not Preserved The `java.nio.channels.Selector` API specifies precisely how selection operations add selection keys to the selector's selected-key set or update the readiness information of selection keys already in the set. The `Selector` implementations in the JDK did not historically implement the latter correctly, meaning that the readiness information was overridden and previous readiness information was not preserved for cases where a channel is selected and its key was already in the selected-key set. This issue has been fixed in JDK 11. This behavior change may surprise code that invokes `select` (or `selectNow`) and doesn't process keys added to the selected-key set before performing another selection operation. JDK-8197957: Removal of sun.nio.ch.disableSystemWideOverlappingFileLockCheck Property The property `sun.nio.ch.disableSystemWideOverlappingFileLockCheck` has been removed. Consequently, compatibility with the older locking approach has also been removed. JDK 6 introduced the system property `sun.nio.ch.disableSystemWideOverlappingFileLockCheck` to control file locking behavior. Specifically, the property was used to enable suppression of JVM-wide file locking and provide compatibility with JDK 1.4 and JDK 5. The old behavior was constrained to check for locks obtained only on the channel instance and not JVM-wide, which is what was actually specified. JDK-8200089: DatagramChannel.send Throws AlreadyConnectedException Instead of IllegalArgumentException Prior to JDK 11, invoking `DatagramChannel.send(ByteBuffer,SocketAddress)` on a `DatagramChannel` connected to an address different from the address specified to the method caused an unspecified `IllegalArgumentException` to be thrown. In Java SE 11, the specification has been clarified to specify `java.nio.channels.AlreadyConnectedException` for this case, and the implementation has been changed to throw the correct exception. JDK-8198692: Separate Blocking and Non-blocking Code Paths The implementations of `SocketChannel`, `ServerSocketChannel`, `DatagramChannel`, `Pipe.SourceChannel` and `Pipe.SinkChannel` have been refactored in JDK 11 to separate the code paths for blocking and non-blocking I/O. This improves performance and also improves reliability for cases where a channel is asynchronously closed or threads doing I/O operations are interrupted. The refactoring results the following behavioral changes: 1. Closing a connected `SocketChannel` that is registered with a `Selector` will now consistently delay closing the underlying connection until the closed channel is flushed from all selectors that it is registered with. Similarly, closing a `ServerSocketChannel` that is registered with `Selector` will now consistently delay closing the underlying listener socket until it is flushed from all selectors that it is registered with. The behavior varied by platform in previous releases. Developers using tools such as `netstat` to monitor network connection should be aware of this change, particularly with libraries or applications that do not perform selection operations in a timely manner to flush closed channels from selectors. 2. Invoking an I/O operation on a selectable channel configured non-blocking and with the interrupt status set no longer closes the channel. 3. Invoking `configureBlocking(false)` on a selectable channel will now block until outstanding blocking I/O operations have completed. The specification has always allowed this but the implementation in the JDK didn't historically wait until blocking I/O operations in progress completed. JDK-8201496: SelectableChannel.register Can Be Invoked While a Selection Operation Is in Progress `java.nio.channels.Selector` historically specified its key set (the set containing the keys representing the channels registered with the selector) to not be thread safe. Selection operations were specified to synchronize on this key set. Additionally, the `register` methods defined by `java.nio.channels.SelectableChannel` (`SocketChannel`, `ServerSocketChannel`, ...) were also specified to synchronize on the selector's key set and therefore block if invoked concurrently with another registration or selection operation. The specification has changed in Java SE 11 so that the selector's key set is specified to be safe for use by concurrent threads. Selection operations are no longer specified to synchronize on the key set. This allows threads to register channels while a selection operation is in progress; the new registration takes effect at the next selection operation. `SelectionKey` `interestOps(int)` has also been re-specified so that it can be called at any time. If invoked while a selection operation is in progress, then it has no effect upon that operation; the change to the key's interest set will be seen by the next selection operation. Code that synchronizes on the `Selector`'s selected-key set is not impacted by this change as selection operations continue to be specified to synchronize on the selected-key set. The `Selector` API is pluggable. `SelectorProvider` implementations that exist outside of the JDK will need to be updated to align their `Selector` implementation with the updated specification. JDK-8201169: Readiness Information Previously Recorded in SelectionKey Ready Set Not Preserved The `java.nio.channels.Selector` API specifies precisely how selection operations add selection keys to the selector's selected-key set or update the readiness information of selection keys already in the set. The `Selector` implementations in the JDK did not historically implement the latter correctly, meaning that the readiness information was overridden and previous readiness information was not preserved for cases where a channel is selected and its key was already in the selected-key set. This issue has been fixed in JDK 11. This behavior change may surprise code that invokes `select` (or `selectNow`) and doesn't process keys added to the selected-key set before performing another selection operation. JDK-8197957: Removal of sun.nio.ch.disableSystemWideOverlappingFileLockCheck Property The property `sun.nio.ch.disableSystemWideOverlappingFileLockCheck` has been removed. Consequently, compatibility with the older locking approach has also been removed. JDK 6 introduced the system property `sun.nio.ch.disableSystemWideOverlappingFileLockCheck` to control file locking behavior. Specifically, the property was used to enable suppression of JVM-wide file locking and provide compatibility with JDK 1.4 and JDK 5. The old behavior was constrained to check for locks obtained only on the channel instance and not JVM-wide, which is what was actually specified. JDK-8200089: DatagramChannel.send Throws AlreadyConnectedException Instead of IllegalArgumentException Prior to JDK 11, invoking `DatagramChannel.send(ByteBuffer,SocketAddress)` on a `DatagramChannel` connected to an address different from the address specified to the method caused an unspecified `IllegalArgumentException` to be thrown. In Java SE 11, the specification has been clarified to specify `java.nio.channels.AlreadyConnectedException` for this case, and the implementation has been changed to throw the correct exception. JDK-8198692: Separate Blocking and Non-blocking Code Paths The implementations of `SocketChannel`, `ServerSocketChannel`, `DatagramChannel`, `Pipe.SourceChannel` and `Pipe.SinkChannel` have been refactored in JDK 11 to separate the code paths for blocking and non-blocking I/O. This improves performance and also improves reliability for cases where a channel is asynchronously closed or threads doing I/O operations are interrupted. The refactoring results the following behavioral changes: 1. Closing a connected `SocketChannel` that is registered with a `Selector` will now consistently delay closing the underlying connection until the closed channel is flushed from all selectors that it is registered with. Similarly, closing a `ServerSocketChannel` that is registered with `Selector` will now consistently delay closing the underlying listener socket until it is flushed from all selectors that it is registered with. The behavior varied by platform in previous releases. Developers using tools such as `netstat` to monitor network connection should be aware of this change, particularly with libraries or applications that do not perform selection operations in a timely manner to flush closed channels from selectors. 2. Invoking an I/O operation on a selectable channel configured non-blocking and with the interrupt status set no longer closes the channel. 3. Invoking `configureBlocking(false)` on a selectable channel will now block until outstanding blocking I/O operations have completed. The specification has always allowed this but the implementation in the JDK didn't historically wait until blocking I/O operations in progress completed. JDK-8201496: SelectableChannel.register Can Be Invoked While a Selection Operation Is in Progress `java.nio.channels.Selector` historically specified its key set (the set containing the keys representing the channels registered with the selector) to not be thread safe. Selection operations were specified to synchronize on this key set. Additionally, the `register` methods defined by `java.nio.channels.SelectableChannel` (`SocketChannel`, `ServerSocketChannel`, ...) were also specified to synchronize on the selector's key set and therefore block if invoked concurrently with another registration or selection operation. The specification has changed in Java SE 11 so that the selector's key set is specified to be safe for use by concurrent threads. Selection operations are no longer specified to synchronize on the key set. This allows threads to register channels while a selection operation is in progress; the new registration takes effect at the next selection operation. `SelectionKey` `interestOps(int)` has also been re-specified so that it can be called at any time. If invoked while a selection operation is in progress, then it has no effect upon that operation; the change to the key's interest set will be seen by the next selection operation. Code that synchronizes on the `Selector`'s selected-key set is not impacted by this change as selection operations continue to be specified to synchronize on the selected-key set. The `Selector` API is pluggable. `SelectorProvider` implementations that exist outside of the JDK will need to be updated to align their `Selector` implementation with the updated specification. JDK-8201169: Readiness Information Previously Recorded in SelectionKey Ready Set Not Preserved The `java.nio.channels.Selector` API specifies precisely how selection operations add selection keys to the selector's selected-key set or update the readiness information of selection keys already in the set. The `Selector` implementations in the JDK did not historically implement the latter correctly, meaning that the readiness information was overridden and previous readiness information was not preserved for cases where a channel is selected and its key was already in the selected-key set. This issue has been fixed in JDK 11. This behavior change may surprise code that invokes `select` (or `selectNow`) and doesn't process keys added to the selected-key set before performing another selection operation. JDK-8197957: Removal of sun.nio.ch.disableSystemWideOverlappingFileLockCheck Property The property `sun.nio.ch.disableSystemWideOverlappingFileLockCheck` has been removed. Consequently, compatibility with the older locking approach has also been removed. JDK 6 introduced the system property `sun.nio.ch.disableSystemWideOverlappingFileLockCheck` to control file locking behavior. Specifically, the property was used to enable suppression of JVM-wide file locking and provide compatibility with JDK 1.4 and JDK 5. The old behavior was constrained to check for locks obtained only on the channel instance and not JVM-wide, which is what was actually specified. JDK-8200089: DatagramChannel.send Throws AlreadyConnectedException Instead of IllegalArgumentException Prior to JDK 11, invoking `DatagramChannel.send(ByteBuffer,SocketAddress)` on a `DatagramChannel` connected to an address different from the address specified to the method caused an unspecified `IllegalArgumentException` to be thrown. In Java SE 11, the specification has been clarified to specify `java.nio.channels.AlreadyConnectedException` for this case, and the implementation has been changed to throw the correct exception. JDK-8198692: Separate Blocking and Non-blocking Code Paths The implementations of `SocketChannel`, `ServerSocketChannel`, `DatagramChannel`, `Pipe.SourceChannel` and `Pipe.SinkChannel` have been refactored in JDK 11 to separate the code paths for blocking and non-blocking I/O. This improves performance and also improves reliability for cases where a channel is asynchronously closed or threads doing I/O operations are interrupted. The refactoring results the following behavioral changes: 1. Closing a connected `SocketChannel` that is registered with a `Selector` will now consistently delay closing the underlying connection until the closed channel is flushed from all selectors that it is registered with. Similarly, closing a `ServerSocketChannel` that is registered with `Selector` will now consistently delay closing the underlying listener socket until it is flushed from all selectors that it is registered with. The behavior varied by platform in previous releases. Developers using tools such as `netstat` to monitor network connection should be aware of this change, particularly with libraries or applications that do not perform selection operations in a timely manner to flush closed channels from selectors. 2. Invoking an I/O operation on a selectable channel configured non-blocking and with the interrupt status set no longer closes the channel. 3. Invoking `configureBlocking(false)` on a selectable channel will now block until outstanding blocking I/O operations have completed. The specification has always allowed this but the implementation in the JDK didn't historically wait until blocking I/O operations in progress completed. JDK-8201496: SelectableChannel.register Can Be Invoked While a Selection Operation Is in Progress `java.nio.channels.Selector` historically specified its key set (the set containing the keys representing the channels registered with the selector) to not be thread safe. Selection operations were specified to synchronize on this key set. Additionally, the `register` methods defined by `java.nio.channels.SelectableChannel` (`SocketChannel`, `ServerSocketChannel`, ...) were also specified to synchronize on the selector's key set and therefore block if invoked concurrently with another registration or selection operation. The specification has changed in Java SE 11 so that the selector's key set is specified to be safe for use by concurrent threads. Selection operations are no longer specified to synchronize on the key set. This allows threads to register channels while a selection operation is in progress; the new registration takes effect at the next selection operation. `SelectionKey` `interestOps(int)` has also been re-specified so that it can be called at any time. If invoked while a selection operation is in progress, then it has no effect upon that operation; the change to the key's interest set will be seen by the next selection operation. Code that synchronizes on the `Selector`'s selected-key set is not impacted by this change as selection operations continue to be specified to synchronize on the selected-key set. The `Selector` API is pluggable. `SelectorProvider` implementations that exist outside of the JDK will need to be updated to align their `Selector` implementation with the updated specification. JDK-8201169: Readiness Information Previously Recorded in SelectionKey Ready Set Not Preserved The `java.nio.channels.Selector` API specifies precisely how selection operations add selection keys to the selector's selected-key set or update the readiness information of selection keys already in the set. The `Selector` implementations in the JDK did not historically implement the latter correctly, meaning that the readiness information was overridden and previous readiness information was not preserved for cases where a channel is selected and its key was already in the selected-key set. This issue has been fixed in JDK 11. This behavior change may surprise code that invokes `select` (or `selectNow`) and doesn't process keys added to the selected-key set before performing another selection operation. JDK-8197957: Removal of sun.nio.ch.disableSystemWideOverlappingFileLockCheck Property The property `sun.nio.ch.disableSystemWideOverlappingFileLockCheck` has been removed. Consequently, compatibility with the older locking approach has also been removed. JDK 6 introduced the system property `sun.nio.ch.disableSystemWideOverlappingFileLockCheck` to control file locking behavior. Specifically, the property was used to enable suppression of JVM-wide file locking and provide compatibility with JDK 1.4 and JDK 5. The old behavior was constrained to check for locks obtained only on the channel instance and not JVM-wide, which is what was actually specified. JDK-8200089: DatagramChannel.send Throws AlreadyConnectedException Instead of IllegalArgumentException Prior to JDK 11, invoking `DatagramChannel.send(ByteBuffer,SocketAddress)` on a `DatagramChannel` connected to an address different from the address specified to the method caused an unspecified `IllegalArgumentException` to be thrown. In Java SE 11, the specification has been clarified to specify `java.nio.channels.AlreadyConnectedException` for this case, and the implementation has been changed to throw the correct exception. JDK-8198692: Separate Blocking and Non-blocking Code Paths The implementations of `SocketChannel`, `ServerSocketChannel`, `DatagramChannel`, `Pipe.SourceChannel` and `Pipe.SinkChannel` have been refactored in JDK 11 to separate the code paths for blocking and non-blocking I/O. This improves performance and also improves reliability for cases where a channel is asynchronously closed or threads doing I/O operations are interrupted. The refactoring results the following behavioral changes: 1. Closing a connected `SocketChannel` that is registered with a `Selector` will now consistently delay closing the underlying connection until the closed channel is flushed from all selectors that it is registered with. Similarly, closing a `ServerSocketChannel` that is registered with `Selector` will now consistently delay closing the underlying listener socket until it is flushed from all selectors that it is registered with. The behavior varied by platform in previous releases. Developers using tools such as `netstat` to monitor network connection should be aware of this change, particularly with libraries or applications that do not perform selection operations in a timely manner to flush closed channels from selectors. 2. Invoking an I/O operation on a selectable channel configured non-blocking and with the interrupt status set no longer closes the channel. 3. Invoking `configureBlocking(false)` on a selectable channel will now block until outstanding blocking I/O operations have completed. The specification has always allowed this but the implementation in the JDK didn't historically wait until blocking I/O operations in progress completed. other-libs: JDK-8195073: JEP 320 Remove the Java EE and CORBA Modules Remove the Java EE and CORBA modules from the Java SE Platform and the JDK. These modules were deprecated in Java SE 9 with the declared intent to remove them in a future release ([JEP 320](http://openjdk.java.net/jeps/320)). The following modules have been removed from Java SE 11 and JDK 11: - `java.xml.ws` (JAX-WS, plus the related technologies SAAJ and Web Services Metadata) - `java.xml.bind` (JAXB) - `java.activation` (JAF) - `java.xml.ws.annotation` (Common Annotations) - `java.corba` (CORBA) - `java.transaction` (JTA) - `java.se.ee` (Aggregator module for the six modules above) - `jdk.xml.ws` (Tools for JAX-WS) - `jdk.xml.bind` (Tools for JAXB) The following JAX-WS tools, from the `jdk.xml.ws` module, are removed: - `wsgen` - `wsimport` The following JAXB tools, from the `jdk.xml.bind` module, are removed: - `schemagen` - `xjc` The following CORBA tools, from the `java.corba` module, are removed: - `idlj` - `orbd` - `servertool` - `tnamesrv` The `rmic` compiler was updated to remove the `-idl` and `-iiop` options. Consequently, the RMI compiler will no longer be able to generate IDL or IIOP stubs and tie classes. In addition, the following system properties are no longer applicable due to the the removal of the Java EE and CORBA modules: - `com.sun.xml.internal.ws.client.ContentNegotiation` - `com.sun.xml.internal.ws.legacyWebMethod` - `javax.xml.bind.context.factory` - `javax.xml.bind.JAXBContext` - `javax.xml.soap.MetaFactory` - `javax.xml.ws.spi.Provider` - `jaxb.fragment` - `jaxb.noNamespaceSchemaLocation` - `jaxb.schemaLocation` - `jaxb.formatted.output` - `jaxb.encoding` - `mail.mime.decodetext.strict` - `mail.mime.encodeeol.strict` - `mail.mime.foldencodedwords` - `mail.mime.foldtext` - `mail.mime.charset` - `saaj.mime.optimization` - `saaj.lazy.contentlength` - `saaj.lazy.contentlength` - `saaj.lazy.mime.optimization` For more detailed information on the removal and possible replacement for the modules, refer to [JEP 320](http://openjdk.java.net/jeps/320). client-libs/java.awt: JDK-8203311: GTK3 Is Now the Default on Linux/Unix Newer versions of Linux, Solaris, and other Unix flavor desktop environments use GTK3, while still supporting GTK2. Previously, the JDK would default to loading the older GTK2 libraries. However, in this release, it defaults to loading GTK3 libraries. Loading is typically triggered by using the Swing GTK Look And Feel. If, for any reason, this causes issues for an application, the old behavior can be restored by using the system property: `-Djdk.gtk.version=2.2` JDK-8201219: Removal of com.sun.awt.AWTUtilities Class The `com.sun.awt.AWTUtilities` class was deprecated with `forRemoval=true` in JDK 10 (JDK-8187253). This class was unused in the JDK and has been removed in this release. JDK-8193697: Description for Toolkit.getImage() and Toolkit.createImage() The changes made under JDK-8033530 introduced an inconsistency between the implementation for and the documentation of the following methods: * `java.awt.Toolkit.getImage(URL u)` * `java.awt.Toolkit.createimage(URL u)` The description in the API document should read: >This method first checks if there is a security manager installed. If so, the method calls the security managers `checkPermission()` method with the corresponding permission to ensure that the access to the image or the image creation is allowed. If the connection to the specified URL requires either URLPermission or SocketPermission, then `URLPermission` is used for security checks. JDK-8203311: GTK3 Is Now the Default on Linux/Unix Newer versions of Linux, Solaris, and other Unix flavor desktop environments use GTK3, while still supporting GTK2. Previously, the JDK would default to loading the older GTK2 libraries. However, in this release, it defaults to loading GTK3 libraries. Loading is typically triggered by using the Swing GTK Look And Feel. If, for any reason, this causes issues for an application, the old behavior can be restored by using the system property: `-Djdk.gtk.version=2.2` JDK-8201219: Removal of com.sun.awt.AWTUtilities Class The `com.sun.awt.AWTUtilities` class was deprecated with `forRemoval=true` in JDK 10 (JDK-8187253). This class was unused in the JDK and has been removed in this release. JDK-8193697: Description for Toolkit.getImage() and Toolkit.createImage() The changes made under JDK-8033530 introduced an inconsistency between the implementation for and the documentation of the following methods: * `java.awt.Toolkit.getImage(URL u)` * `java.awt.Toolkit.createimage(URL u)` The description in the API document should read: >This method first checks if there is a security manager installed. If so, the method calls the security managers `checkPermission()` method with the corresponding permission to ensure that the access to the image or the image creation is allowed. If the connection to the specified URL requires either URLPermission or SocketPermission, then `URLPermission` is used for security checks. JDK-8203311: GTK3 Is Now the Default on Linux/Unix Newer versions of Linux, Solaris, and other Unix flavor desktop environments use GTK3, while still supporting GTK2. Previously, the JDK would default to loading the older GTK2 libraries. However, in this release, it defaults to loading GTK3 libraries. Loading is typically triggered by using the Swing GTK Look And Feel. If, for any reason, this causes issues for an application, the old behavior can be restored by using the system property: `-Djdk.gtk.version=2.2` JDK-8201219: Removal of com.sun.awt.AWTUtilities Class The `com.sun.awt.AWTUtilities` class was deprecated with `forRemoval=true` in JDK 10 (JDK-8187253). This class was unused in the JDK and has been removed in this release. JDK-8193697: Description for Toolkit.getImage() and Toolkit.createImage() The changes made under JDK-8033530 introduced an inconsistency between the implementation for and the documentation of the following methods: * `java.awt.Toolkit.getImage(URL u)` * `java.awt.Toolkit.createimage(URL u)` The description in the API document should read: >This method first checks if there is a security manager installed. If so, the method calls the security managers `checkPermission()` method with the corresponding permission to ensure that the access to the image or the image creation is allowed. If the connection to the specified URL requires either URLPermission or SocketPermission, then `URLPermission` is used for security checks. hotspot/gc: JDK-8205334: JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental) The Z Garbage Collector, also known as ZGC, is a scalable low latency garbage collector ([JEP 333](http://openjdk.java.net/jeps/333)). It is designed to meet the following goals: * Pause times do not exceed 10 ms * Pause times do not increase with the heap or live-set size * Handle heaps ranging from a few hundred megabytes to multi terabytes in size At its core, ZGC is a concurrent garbage collector, meaning that all heavy lifting work (marking, compaction, reference processing, string table cleaning, etc) is done while Java threads continue to execute. This greatly limits the negative impact that garbage collection has on application response times. ZGC is included as an *experimental feature*. To enable it, the `-XX:+UnlockExperimentalVMOptions` option will therefore need to be used in combination with the `-XX:+UseZGC` option. This experimental version of ZGC has the following limitations: * It is only available on Linux/x64. * Using compressed oops and/or compressed class points is not supported. The `-XX:+UseCompressedOops` and `-XX:+UseCompressedClassPointers` options are disabled by default. Enabling them will have no effect. * Class unloading is not supported. The `-XX:+ClassUnloading` and `-XX:+ClassUnloadingWithConcurrentMark` options are disabled by default. Enabling them will have no effect. * Using ZGC in combination with Graal is not supported. JDK-8199513: Garbage Collectors Adaptively Scale the Number of Threads by Default The number of threads garbage collectors use in the garbage collection stop-the-world pauses determine the number of threads to use based on the maximum size of the Java heap. The flag -XX:UseDynamicNumberOfGCThreads is now true (enabled) by default. This improves startup time and reduces resource usage particularly for Java applications run with a small Java heap. If you experience performance reductions particularly on applications that use a small amount of Java heap, you can disable this new behavior by specifying -XX:- UseDynamicNumberOfGCThreads on the command line. JDK-8204181: JEP 318: Epsilon, A No-Op Garbage Collector Epsilon GC is the new experimental no-op garbage collector. Epsilon GC only handles memory allocation, and does not implement any memory reclamation mechanism. It is useful for performance testing, to contrast costs/benefits of other GCs. It can be used to conveniently assert memory footprint and memory pressure in tests. In extreme cases, it might be useful with very short lived jobs, where memory reclamation would happen at JVM termination, or getting the last-drop latency improvements in low-garbage applications. See more discussion about its use and tradeoffs in [JEP 318](http://openjdk.java.net/jeps/318). JDK-8205325: Fail Immediately If a GC That Is Unavailable Is Selected Previously, if an unavailable garbage collector (for example, the G1 garbage collector was not present in "minimal" JVM builds) was selected by the user on the command line, then the JVM would issue a warning and continue execution, by silently selecting one of the available garbage collectors. This behavior has been changed. The JVM will now print an error message and immediately terminate if the user selects an unavailable garbage collector. JDK-8205328: G1 Enables Adaptive Parallel Reference Processing by Default By default, G1 now determines the optimal number of threads to use for `java.lang.ref.Reference` processing during garbage collection. The flag, `-XX:ParallelRefProcEnabled`, is now `true` (enabled) by default. The change improves this phase of the garbage collection pause significantly on machines with more than one thread available for garbage collection. If you experience increased garbage collection pauses, you can revert to the original behavior by specifying `-XX:-ParallelRefProcEnabled` on the command line. The adaptiveness of `java.lang.ref.Reference` processing can be tuned by using the experimental option, `-XX:ReferencesPerThread` (default value: 1000). JDK-8205376: JVM Crash during G1 GC A klass that has been considered unreachable by the concurrent marking of G1, can be looked up in the `ClassLoaderData/SystemDictionary`, and its `_java_mirror` or `_class_loader` fields can be stored in a root or any other reachable object making it alive again. Whenever a klass is resurrected in this manner, the SATB part of G1 needs to be notified about this, otherwise, the concurrent marking remark phase will erroneously unload that klass. In this particular crash, while G1 was doing concurrent marking and had prepared its list of unreachable classes, JVMTI on a Java thread could traverse classes in the CLD and store thread-local JNIHandles for the java_mirror of the loaded classes. G1 did not have knowledge of these thread-local JNIHandles, and in the remark phase, it unloaded classes per its prior knowledge of unreachable classes. When these JNIHandles were later scanned, it lead to a crash. This fix for JDK-8187577 informs G1's SATB that a klass has been resurrected and should not be unloaded. JDK-8164431: New PerfCounters for STW Phases on Concurrent GC Are Available A new GC performance counter has been added for pauses during the concurrent phase. This counter will be listed by `jstat` under the CGC (concurrent GC) heading. This information is only available for GCs with a concurrent phase and is GC specific: * G1 includes remark and cleanup pauses * CMS includes initial mark and remark pauses For CMS, these pauses were previously included in the time listed by `jstat` under the FGC (full GC) heading. The information is also available via the `jcmd` by using `PerfCounter.print`. JDK-8205334: JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental) The Z Garbage Collector, also known as ZGC, is a scalable low latency garbage collector ([JEP 333](http://openjdk.java.net/jeps/333)). It is designed to meet the following goals: * Pause times do not exceed 10 ms * Pause times do not increase with the heap or live-set size * Handle heaps ranging from a few hundred megabytes to multi terabytes in size At its core, ZGC is a concurrent garbage collector, meaning that all heavy lifting work (marking, compaction, reference processing, string table cleaning, etc) is done while Java threads continue to execute. This greatly limits the negative impact that garbage collection has on application response times. ZGC is included as an *experimental feature*. To enable it, the `-XX:+UnlockExperimentalVMOptions` option will therefore need to be used in combination with the `-XX:+UseZGC` option. This experimental version of ZGC has the following limitations: * It is only available on Linux/x64. * Using compressed oops and/or compressed class points is not supported. The `-XX:+UseCompressedOops` and `-XX:+UseCompressedClassPointers` options are disabled by default. Enabling them will have no effect. * Class unloading is not supported. The `-XX:+ClassUnloading` and `-XX:+ClassUnloadingWithConcurrentMark` options are disabled by default. Enabling them will have no effect. * Using ZGC in combination with Graal is not supported. JDK-8199513: Garbage Collectors Adaptively Scale the Number of Threads by Default The number of threads garbage collectors use in the garbage collection stop-the-world pauses determine the number of threads to use based on the maximum size of the Java heap. The flag -XX:UseDynamicNumberOfGCThreads is now true (enabled) by default. This improves startup time and reduces resource usage particularly for Java applications run with a small Java heap. If you experience performance reductions particularly on applications that use a small amount of Java heap, you can disable this new behavior by specifying -XX:- UseDynamicNumberOfGCThreads on the command line. JDK-8204181: JEP 318: Epsilon, A No-Op Garbage Collector Epsilon GC is the new experimental no-op garbage collector. Epsilon GC only handles memory allocation, and does not implement any memory reclamation mechanism. It is useful for performance testing, to contrast costs/benefits of other GCs. It can be used to conveniently assert memory footprint and memory pressure in tests. In extreme cases, it might be useful with very short lived jobs, where memory reclamation would happen at JVM termination, or getting the last-drop latency improvements in low-garbage applications. See more discussion about its use and tradeoffs in [JEP 318](http://openjdk.java.net/jeps/318). JDK-8205325: Fail Immediately If a GC That Is Unavailable Is Selected Previously, if an unavailable garbage collector (for example, the G1 garbage collector was not present in "minimal" JVM builds) was selected by the user on the command line, then the JVM would issue a warning and continue execution, by silently selecting one of the available garbage collectors. This behavior has been changed. The JVM will now print an error message and immediately terminate if the user selects an unavailable garbage collector. JDK-8205328: G1 Enables Adaptive Parallel Reference Processing by Default By default, G1 now determines the optimal number of threads to use for `java.lang.ref.Reference` processing during garbage collection. The flag, `-XX:ParallelRefProcEnabled`, is now `true` (enabled) by default. The change improves this phase of the garbage collection pause significantly on machines with more than one thread available for garbage collection. If you experience increased garbage collection pauses, you can revert to the original behavior by specifying `-XX:-ParallelRefProcEnabled` on the command line. The adaptiveness of `java.lang.ref.Reference` processing can be tuned by using the experimental option, `-XX:ReferencesPerThread` (default value: 1000). JDK-8205376: JVM Crash during G1 GC A klass that has been considered unreachable by the concurrent marking of G1, can be looked up in the `ClassLoaderData/SystemDictionary`, and its `_java_mirror` or `_class_loader` fields can be stored in a root or any other reachable object making it alive again. Whenever a klass is resurrected in this manner, the SATB part of G1 needs to be notified about this, otherwise, the concurrent marking remark phase will erroneously unload that klass. In this particular crash, while G1 was doing concurrent marking and had prepared its list of unreachable classes, JVMTI on a Java thread could traverse classes in the CLD and store thread-local JNIHandles for the java_mirror of the loaded classes. G1 did not have knowledge of these thread-local JNIHandles, and in the remark phase, it unloaded classes per its prior knowledge of unreachable classes. When these JNIHandles were later scanned, it lead to a crash. This fix for JDK-8187577 informs G1's SATB that a klass has been resurrected and should not be unloaded. JDK-8164431: New PerfCounters for STW Phases on Concurrent GC Are Available A new GC performance counter has been added for pauses during the concurrent phase. This counter will be listed by `jstat` under the CGC (concurrent GC) heading. This information is only available for GCs with a concurrent phase and is GC specific: * G1 includes remark and cleanup pauses * CMS includes initial mark and remark pauses For CMS, these pauses were previously included in the time listed by `jstat` under the FGC (full GC) heading. The information is also available via the `jcmd` by using `PerfCounter.print`. JDK-8205334: JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental) The Z Garbage Collector, also known as ZGC, is a scalable low latency garbage collector ([JEP 333](http://openjdk.java.net/jeps/333)). It is designed to meet the following goals: * Pause times do not exceed 10 ms * Pause times do not increase with the heap or live-set size * Handle heaps ranging from a few hundred megabytes to multi terabytes in size At its core, ZGC is a concurrent garbage collector, meaning that all heavy lifting work (marking, compaction, reference processing, string table cleaning, etc) is done while Java threads continue to execute. This greatly limits the negative impact that garbage collection has on application response times. ZGC is included as an *experimental feature*. To enable it, the `-XX:+UnlockExperimentalVMOptions` option will therefore need to be used in combination with the `-XX:+UseZGC` option. This experimental version of ZGC has the following limitations: * It is only available on Linux/x64. * Using compressed oops and/or compressed class points is not supported. The `-XX:+UseCompressedOops` and `-XX:+UseCompressedClassPointers` options are disabled by default. Enabling them will have no effect. * Class unloading is not supported. The `-XX:+ClassUnloading` and `-XX:+ClassUnloadingWithConcurrentMark` options are disabled by default. Enabling them will have no effect. * Using ZGC in combination with Graal is not supported. JDK-8199513: Garbage Collectors Adaptively Scale the Number of Threads by Default The number of threads garbage collectors use in the garbage collection stop-the-world pauses determine the number of threads to use based on the maximum size of the Java heap. The flag -XX:UseDynamicNumberOfGCThreads is now true (enabled) by default. This improves startup time and reduces resource usage particularly for Java applications run with a small Java heap. If you experience performance reductions particularly on applications that use a small amount of Java heap, you can disable this new behavior by specifying -XX:- UseDynamicNumberOfGCThreads on the command line. JDK-8204181: JEP 318: Epsilon, A No-Op Garbage Collector Epsilon GC is the new experimental no-op garbage collector. Epsilon GC only handles memory allocation, and does not implement any memory reclamation mechanism. It is useful for performance testing, to contrast costs/benefits of other GCs. It can be used to conveniently assert memory footprint and memory pressure in tests. In extreme cases, it might be useful with very short lived jobs, where memory reclamation would happen at JVM termination, or getting the last-drop latency improvements in low-garbage applications. See more discussion about its use and tradeoffs in [JEP 318](http://openjdk.java.net/jeps/318). JDK-8205325: Fail Immediately If a GC That Is Unavailable Is Selected Previously, if an unavailable garbage collector (for example, the G1 garbage collector was not present in "minimal" JVM builds) was selected by the user on the command line, then the JVM would issue a warning and continue execution, by silently selecting one of the available garbage collectors. This behavior has been changed. The JVM will now print an error message and immediately terminate if the user selects an unavailable garbage collector. JDK-8205328: G1 Enables Adaptive Parallel Reference Processing by Default By default, G1 now determines the optimal number of threads to use for `java.lang.ref.Reference` processing during garbage collection. The flag, `-XX:ParallelRefProcEnabled`, is now `true` (enabled) by default. The change improves this phase of the garbage collection pause significantly on machines with more than one thread available for garbage collection. If you experience increased garbage collection pauses, you can revert to the original behavior by specifying `-XX:-ParallelRefProcEnabled` on the command line. The adaptiveness of `java.lang.ref.Reference` processing can be tuned by using the experimental option, `-XX:ReferencesPerThread` (default value: 1000). JDK-8205376: JVM Crash during G1 GC A klass that has been considered unreachable by the concurrent marking of G1, can be looked up in the `ClassLoaderData/SystemDictionary`, and its `_java_mirror` or `_class_loader` fields can be stored in a root or any other reachable object making it alive again. Whenever a klass is resurrected in this manner, the SATB part of G1 needs to be notified about this, otherwise, the concurrent marking remark phase will erroneously unload that klass. In this particular crash, while G1 was doing concurrent marking and had prepared its list of unreachable classes, JVMTI on a Java thread could traverse classes in the CLD and store thread-local JNIHandles for the java_mirror of the loaded classes. G1 did not have knowledge of these thread-local JNIHandles, and in the remark phase, it unloaded classes per its prior knowledge of unreachable classes. When these JNIHandles were later scanned, it lead to a crash. This fix for JDK-8187577 informs G1's SATB that a klass has been resurrected and should not be unloaded. JDK-8164431: New PerfCounters for STW Phases on Concurrent GC Are Available A new GC performance counter has been added for pauses during the concurrent phase. This counter will be listed by `jstat` under the CGC (concurrent GC) heading. This information is only available for GCs with a concurrent phase and is GC specific: * G1 includes remark and cleanup pauses * CMS includes initial mark and remark pauses For CMS, these pauses were previously included in the time listed by `jstat` under the FGC (full GC) heading. The information is also available via the `jcmd` by using `PerfCounter.print`. JDK-8205334: JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental) The Z Garbage Collector, also known as ZGC, is a scalable low latency garbage collector ([JEP 333](http://openjdk.java.net/jeps/333)). It is designed to meet the following goals: * Pause times do not exceed 10 ms * Pause times do not increase with the heap or live-set size * Handle heaps ranging from a few hundred megabytes to multi terabytes in size At its core, ZGC is a concurrent garbage collector, meaning that all heavy lifting work (marking, compaction, reference processing, string table cleaning, etc) is done while Java threads continue to execute. This greatly limits the negative impact that garbage collection has on application response times. ZGC is included as an *experimental feature*. To enable it, the `-XX:+UnlockExperimentalVMOptions` option will therefore need to be used in combination with the `-XX:+UseZGC` option. This experimental version of ZGC has the following limitations: * It is only available on Linux/x64. * Using compressed oops and/or compressed class points is not supported. The `-XX:+UseCompressedOops` and `-XX:+UseCompressedClassPointers` options are disabled by default. Enabling them will have no effect. * Class unloading is not supported. The `-XX:+ClassUnloading` and `-XX:+ClassUnloadingWithConcurrentMark` options are disabled by default. Enabling them will have no effect. * Using ZGC in combination with Graal is not supported. JDK-8199513: Garbage Collectors Adaptively Scale the Number of Threads by Default The number of threads garbage collectors use in the garbage collection stop-the-world pauses determine the number of threads to use based on the maximum size of the Java heap. The flag -XX:UseDynamicNumberOfGCThreads is now true (enabled) by default. This improves startup time and reduces resource usage particularly for Java applications run with a small Java heap. If you experience performance reductions particularly on applications that use a small amount of Java heap, you can disable this new behavior by specifying -XX:- UseDynamicNumberOfGCThreads on the command line. JDK-8204181: JEP 318: Epsilon, A No-Op Garbage Collector Epsilon GC is the new experimental no-op garbage collector. Epsilon GC only handles memory allocation, and does not implement any memory reclamation mechanism. It is useful for performance testing, to contrast costs/benefits of other GCs. It can be used to conveniently assert memory footprint and memory pressure in tests. In extreme cases, it might be useful with very short lived jobs, where memory reclamation would happen at JVM termination, or getting the last-drop latency improvements in low-garbage applications. See more discussion about its use and tradeoffs in [JEP 318](http://openjdk.java.net/jeps/318). JDK-8205325: Fail Immediately If a GC That Is Unavailable Is Selected Previously, if an unavailable garbage collector (for example, the G1 garbage collector was not present in "minimal" JVM builds) was selected by the user on the command line, then the JVM would issue a warning and continue execution, by silently selecting one of the available garbage collectors. This behavior has been changed. The JVM will now print an error message and immediately terminate if the user selects an unavailable garbage collector. JDK-8205328: G1 Enables Adaptive Parallel Reference Processing by Default By default, G1 now determines the optimal number of threads to use for `java.lang.ref.Reference` processing during garbage collection. The flag, `-XX:ParallelRefProcEnabled`, is now `true` (enabled) by default. The change improves this phase of the garbage collection pause significantly on machines with more than one thread available for garbage collection. If you experience increased garbage collection pauses, you can revert to the original behavior by specifying `-XX:-ParallelRefProcEnabled` on the command line. The adaptiveness of `java.lang.ref.Reference` processing can be tuned by using the experimental option, `-XX:ReferencesPerThread` (default value: 1000). JDK-8205376: JVM Crash during G1 GC A klass that has been considered unreachable by the concurrent marking of G1, can be looked up in the `ClassLoaderData/SystemDictionary`, and its `_java_mirror` or `_class_loader` fields can be stored in a root or any other reachable object making it alive again. Whenever a klass is resurrected in this manner, the SATB part of G1 needs to be notified about this, otherwise, the concurrent marking remark phase will erroneously unload that klass. In this particular crash, while G1 was doing concurrent marking and had prepared its list of unreachable classes, JVMTI on a Java thread could traverse classes in the CLD and store thread-local JNIHandles for the java_mirror of the loaded classes. G1 did not have knowledge of these thread-local JNIHandles, and in the remark phase, it unloaded classes per its prior knowledge of unreachable classes. When these JNIHandles were later scanned, it lead to a crash. This fix for JDK-8187577 informs G1's SATB that a klass has been resurrected and should not be unloaded. JDK-8164431: New PerfCounters for STW Phases on Concurrent GC Are Available A new GC performance counter has been added for pauses during the concurrent phase. This counter will be listed by `jstat` under the CGC (concurrent GC) heading. This information is only available for GCs with a concurrent phase and is GC specific: * G1 includes remark and cleanup pauses * CMS includes initial mark and remark pauses For CMS, these pauses were previously included in the time listed by `jstat` under the FGC (full GC) heading. The information is also available via the `jcmd` by using `PerfCounter.print`. JDK-8205334: JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental) The Z Garbage Collector, also known as ZGC, is a scalable low latency garbage collector ([JEP 333](http://openjdk.java.net/jeps/333)). It is designed to meet the following goals: * Pause times do not exceed 10 ms * Pause times do not increase with the heap or live-set size * Handle heaps ranging from a few hundred megabytes to multi terabytes in size At its core, ZGC is a concurrent garbage collector, meaning that all heavy lifting work (marking, compaction, reference processing, string table cleaning, etc) is done while Java threads continue to execute. This greatly limits the negative impact that garbage collection has on application response times. ZGC is included as an *experimental feature*. To enable it, the `-XX:+UnlockExperimentalVMOptions` option will therefore need to be used in combination with the `-XX:+UseZGC` option. This experimental version of ZGC has the following limitations: * It is only available on Linux/x64. * Using compressed oops and/or compressed class points is not supported. The `-XX:+UseCompressedOops` and `-XX:+UseCompressedClassPointers` options are disabled by default. Enabling them will have no effect. * Class unloading is not supported. The `-XX:+ClassUnloading` and `-XX:+ClassUnloadingWithConcurrentMark` options are disabled by default. Enabling them will have no effect. * Using ZGC in combination with Graal is not supported. JDK-8199513: Garbage Collectors Adaptively Scale the Number of Threads by Default The number of threads garbage collectors use in the garbage collection stop-the-world pauses determine the number of threads to use based on the maximum size of the Java heap. The flag -XX:UseDynamicNumberOfGCThreads is now true (enabled) by default. This improves startup time and reduces resource usage particularly for Java applications run with a small Java heap. If you experience performance reductions particularly on applications that use a small amount of Java heap, you can disable this new behavior by specifying -XX:- UseDynamicNumberOfGCThreads on the command line. JDK-8204181: JEP 318: Epsilon, A No-Op Garbage Collector Epsilon GC is the new experimental no-op garbage collector. Epsilon GC only handles memory allocation, and does not implement any memory reclamation mechanism. It is useful for performance testing, to contrast costs/benefits of other GCs. It can be used to conveniently assert memory footprint and memory pressure in tests. In extreme cases, it might be useful with very short lived jobs, where memory reclamation would happen at JVM termination, or getting the last-drop latency improvements in low-garbage applications. See more discussion about its use and tradeoffs in [JEP 318](http://openjdk.java.net/jeps/318). JDK-8205325: Fail Immediately If a GC That Is Unavailable Is Selected Previously, if an unavailable garbage collector (for example, the G1 garbage collector was not present in "minimal" JVM builds) was selected by the user on the command line, then the JVM would issue a warning and continue execution, by silently selecting one of the available garbage collectors. This behavior has been changed. The JVM will now print an error message and immediately terminate if the user selects an unavailable garbage collector. JDK-8205328: G1 Enables Adaptive Parallel Reference Processing by Default By default, G1 now determines the optimal number of threads to use for `java.lang.ref.Reference` processing during garbage collection. The flag, `-XX:ParallelRefProcEnabled`, is now `true` (enabled) by default. The change improves this phase of the garbage collection pause significantly on machines with more than one thread available for garbage collection. If you experience increased garbage collection pauses, you can revert to the original behavior by specifying `-XX:-ParallelRefProcEnabled` on the command line. The adaptiveness of `java.lang.ref.Reference` processing can be tuned by using the experimental option, `-XX:ReferencesPerThread` (default value: 1000). JDK-8205376: JVM Crash during G1 GC A klass that has been considered unreachable by the concurrent marking of G1, can be looked up in the `ClassLoaderData/SystemDictionary`, and its `_java_mirror` or `_class_loader` fields can be stored in a root or any other reachable object making it alive again. Whenever a klass is resurrected in this manner, the SATB part of G1 needs to be notified about this, otherwise, the concurrent marking remark phase will erroneously unload that klass. In this particular crash, while G1 was doing concurrent marking and had prepared its list of unreachable classes, JVMTI on a Java thread could traverse classes in the CLD and store thread-local JNIHandles for the java_mirror of the loaded classes. G1 did not have knowledge of these thread-local JNIHandles, and in the remark phase, it unloaded classes per its prior knowledge of unreachable classes. When these JNIHandles were later scanned, it lead to a crash. This fix for JDK-8187577 informs G1's SATB that a klass has been resurrected and should not be unloaded. JDK-8164431: New PerfCounters for STW Phases on Concurrent GC Are Available A new GC performance counter has been added for pauses during the concurrent phase. This counter will be listed by `jstat` under the CGC (concurrent GC) heading. This information is only available for GCs with a concurrent phase and is GC specific: * G1 includes remark and cleanup pauses * CMS includes initial mark and remark pauses For CMS, these pauses were previously included in the time listed by `jstat` under the FGC (full GC) heading. The information is also available via the `jcmd` by using `PerfCounter.print`. JDK-8205334: JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental) The Z Garbage Collector, also known as ZGC, is a scalable low latency garbage collector ([JEP 333](http://openjdk.java.net/jeps/333)). It is designed to meet the following goals: * Pause times do not exceed 10 ms * Pause times do not increase with the heap or live-set size * Handle heaps ranging from a few hundred megabytes to multi terabytes in size At its core, ZGC is a concurrent garbage collector, meaning that all heavy lifting work (marking, compaction, reference processing, string table cleaning, etc) is done while Java threads continue to execute. This greatly limits the negative impact that garbage collection has on application response times. ZGC is included as an *experimental feature*. To enable it, the `-XX:+UnlockExperimentalVMOptions` option will therefore need to be used in combination with the `-XX:+UseZGC` option. This experimental version of ZGC has the following limitations: * It is only available on Linux/x64. * Using compressed oops and/or compressed class points is not supported. The `-XX:+UseCompressedOops` and `-XX:+UseCompressedClassPointers` options are disabled by default. Enabling them will have no effect. * Class unloading is not supported. The `-XX:+ClassUnloading` and `-XX:+ClassUnloadingWithConcurrentMark` options are disabled by default. Enabling them will have no effect. * Using ZGC in combination with Graal is not supported. JDK-8199513: Garbage Collectors Adaptively Scale the Number of Threads by Default The number of threads garbage collectors use in the garbage collection stop-the-world pauses determine the number of threads to use based on the maximum size of the Java heap. The flag -XX:UseDynamicNumberOfGCThreads is now true (enabled) by default. This improves startup time and reduces resource usage particularly for Java applications run with a small Java heap. If you experience performance reductions particularly on applications that use a small amount of Java heap, you can disable this new behavior by specifying -XX:- UseDynamicNumberOfGCThreads on the command line. JDK-8204181: JEP 318: Epsilon, A No-Op Garbage Collector Epsilon GC is the new experimental no-op garbage collector. Epsilon GC only handles memory allocation, and does not implement any memory reclamation mechanism. It is useful for performance testing, to contrast costs/benefits of other GCs. It can be used to conveniently assert memory footprint and memory pressure in tests. In extreme cases, it might be useful with very short lived jobs, where memory reclamation would happen at JVM termination, or getting the last-drop latency improvements in low-garbage applications. See more discussion about its use and tradeoffs in [JEP 318](http://openjdk.java.net/jeps/318). JDK-8205325: Fail Immediately If a GC That Is Unavailable Is Selected Previously, if an unavailable garbage collector (for example, the G1 garbage collector was not present in "minimal" JVM builds) was selected by the user on the command line, then the JVM would issue a warning and continue execution, by silently selecting one of the available garbage collectors. This behavior has been changed. The JVM will now print an error message and immediately terminate if the user selects an unavailable garbage collector. JDK-8205328: G1 Enables Adaptive Parallel Reference Processing by Default By default, G1 now determines the optimal number of threads to use for `java.lang.ref.Reference` processing during garbage collection. The flag, `-XX:ParallelRefProcEnabled`, is now `true` (enabled) by default. The change improves this phase of the garbage collection pause significantly on machines with more than one thread available for garbage collection. If you experience increased garbage collection pauses, you can revert to the original behavior by specifying `-XX:-ParallelRefProcEnabled` on the command line. The adaptiveness of `java.lang.ref.Reference` processing can be tuned by using the experimental option, `-XX:ReferencesPerThread` (default value: 1000). JDK-8205376: JVM Crash during G1 GC A klass that has been considered unreachable by the concurrent marking of G1, can be looked up in the `ClassLoaderData/SystemDictionary`, and its `_java_mirror` or `_class_loader` fields can be stored in a root or any other reachable object making it alive again. Whenever a klass is resurrected in this manner, the SATB part of G1 needs to be notified about this, otherwise, the concurrent marking remark phase will erroneously unload that klass. In this particular crash, while G1 was doing concurrent marking and had prepared its list of unreachable classes, JVMTI on a Java thread could traverse classes in the CLD and store thread-local JNIHandles for the java_mirror of the loaded classes. G1 did not have knowledge of these thread-local JNIHandles, and in the remark phase, it unloaded classes per its prior knowledge of unreachable classes. When these JNIHandles were later scanned, it lead to a crash. This fix for JDK-8187577 informs G1's SATB that a klass has been resurrected and should not be unloaded. JDK-8164431: New PerfCounters for STW Phases on Concurrent GC Are Available A new GC performance counter has been added for pauses during the concurrent phase. This counter will be listed by `jstat` under the CGC (concurrent GC) heading. This information is only available for GCs with a concurrent phase and is GC specific: * G1 includes remark and cleanup pauses * CMS includes initial mark and remark pauses For CMS, these pauses were previously included in the time listed by `jstat` under the FGC (full GC) heading. The information is also available via the `jcmd` by using `PerfCounter.print`. JDK-8205334: JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental) The Z Garbage Collector, also known as ZGC, is a scalable low latency garbage collector ([JEP 333](http://openjdk.java.net/jeps/333)). It is designed to meet the following goals: * Pause times do not exceed 10 ms * Pause times do not increase with the heap or live-set size * Handle heaps ranging from a few hundred megabytes to multi terabytes in size At its core, ZGC is a concurrent garbage collector, meaning that all heavy lifting work (marking, compaction, reference processing, string table cleaning, etc) is done while Java threads continue to execute. This greatly limits the negative impact that garbage collection has on application response times. ZGC is included as an *experimental feature*. To enable it, the `-XX:+UnlockExperimentalVMOptions` option will therefore need to be used in combination with the `-XX:+UseZGC` option. This experimental version of ZGC has the following limitations: * It is only available on Linux/x64. * Using compressed oops and/or compressed class points is not supported. The `-XX:+UseCompressedOops` and `-XX:+UseCompressedClassPointers` options are disabled by default. Enabling them will have no effect. * Class unloading is not supported. The `-XX:+ClassUnloading` and `-XX:+ClassUnloadingWithConcurrentMark` options are disabled by default. Enabling them will have no effect. * Using ZGC in combination with Graal is not supported. JDK-8199513: Garbage Collectors Adaptively Scale the Number of Threads by Default The number of threads garbage collectors use in the garbage collection stop-the-world pauses determine the number of threads to use based on the maximum size of the Java heap. The flag -XX:UseDynamicNumberOfGCThreads is now true (enabled) by default. This improves startup time and reduces resource usage particularly for Java applications run with a small Java heap. If you experience performance reductions particularly on applications that use a small amount of Java heap, you can disable this new behavior by specifying -XX:- UseDynamicNumberOfGCThreads on the command line. JDK-8204181: JEP 318: Epsilon, A No-Op Garbage Collector Epsilon GC is the new experimental no-op garbage collector. Epsilon GC only handles memory allocation, and does not implement any memory reclamation mechanism. It is useful for performance testing, to contrast costs/benefits of other GCs. It can be used to conveniently assert memory footprint and memory pressure in tests. In extreme cases, it might be useful with very short lived jobs, where memory reclamation would happen at JVM termination, or getting the last-drop latency improvements in low-garbage applications. See more discussion about its use and tradeoffs in [JEP 318](http://openjdk.java.net/jeps/318). JDK-8205325: Fail Immediately If a GC That Is Unavailable Is Selected Previously, if an unavailable garbage collector (for example, the G1 garbage collector was not present in "minimal" JVM builds) was selected by the user on the command line, then the JVM would issue a warning and continue execution, by silently selecting one of the available garbage collectors. This behavior has been changed. The JVM will now print an error message and immediately terminate if the user selects an unavailable garbage collector. JDK-8205328: G1 Enables Adaptive Parallel Reference Processing by Default By default, G1 now determines the optimal number of threads to use for `java.lang.ref.Reference` processing during garbage collection. The flag, `-XX:ParallelRefProcEnabled`, is now `true` (enabled) by default. The change improves this phase of the garbage collection pause significantly on machines with more than one thread available for garbage collection. If you experience increased garbage collection pauses, you can revert to the original behavior by specifying `-XX:-ParallelRefProcEnabled` on the command line. The adaptiveness of `java.lang.ref.Reference` processing can be tuned by using the experimental option, `-XX:ReferencesPerThread` (default value: 1000). JDK-8205376: JVM Crash during G1 GC A klass that has been considered unreachable by the concurrent marking of G1, can be looked up in the `ClassLoaderData/SystemDictionary`, and its `_java_mirror` or `_class_loader` fields can be stored in a root or any other reachable object making it alive again. Whenever a klass is resurrected in this manner, the SATB part of G1 needs to be notified about this, otherwise, the concurrent marking remark phase will erroneously unload that klass. In this particular crash, while G1 was doing concurrent marking and had prepared its list of unreachable classes, JVMTI on a Java thread could traverse classes in the CLD and store thread-local JNIHandles for the java_mirror of the loaded classes. G1 did not have knowledge of these thread-local JNIHandles, and in the remark phase, it unloaded classes per its prior knowledge of unreachable classes. When these JNIHandles were later scanned, it lead to a crash. This fix for JDK-8187577 informs G1's SATB that a klass has been resurrected and should not be unloaded. JDK-8164431: New PerfCounters for STW Phases on Concurrent GC Are Available A new GC performance counter has been added for pauses during the concurrent phase. This counter will be listed by `jstat` under the CGC (concurrent GC) heading. This information is only available for GCs with a concurrent phase and is GC specific: * G1 includes remark and cleanup pauses * CMS includes initial mark and remark pauses For CMS, these pauses were previously included in the time listed by `jstat` under the FGC (full GC) heading. The information is also available via the `jcmd` by using `PerfCounter.print`. client-libs/javax.imageio: JDK-8204188: Oracle JDK's javax.imageio JPEG Plugin No Longer Supports Images with alpha Previously, the Oracle JDK used proprietary extensions to the widely used IJG JPEG library in providing optional color space support. This was used to support PhotoYCC and images with an alpha component on both reading and writing. This optional support has been removed in Oracle JDK 11. Encountering encoded JPEG images in any of these formats is unlikely, unless they were previously encoded by an earlier version of the Oracle JDK. However, if they are encountered, decoding will now fail with an exception. Writing an image with an alpha channel will also fail with an exception. The most probable scenario for problems are applications which are unaware that they rely on this support. This could fail with an exception if the ImageWriter is called directly or if the Image I/O convenience methods are used. The `write()` method will now return `false,` meaning that it did not write the image. A carefully written application should check for these scenarios, which will mitigate this. Note that the OpenJDK has never had this optional proprietary support. It has always failed and generated exceptions in these scenarios. For detailed information about what is no longer supported, refer to the optional color space support in the Java Image I/O JPEG Metadata specification: [https://docs.oracle.com/javase/10/docs/api/javax/imageio/metadata/doc-files/jpeg_metadata.html#color](https://docs.oracle.com/javase/10/docs/api/javax/imageio/metadata/doc-files/jpeg_metadata.html#color) core-svc/java.lang.management: JDK-8179909: Removal of SNMP Agent The `jdk.snmp` module has been removed. As a result, the following `com.sun.management.snmp.*` properties are no-op when set by using the `-D` option or the `management.properties` configuration. - `com.sun.management.snmp.port` - `com.sun.management.snmp.trap` - `com.sun.management.snmp.interface` - `com.sun.management.snmp.acl` - `com.sun.management.snmp.acl.file` ALL FIXED ISSUES, BY COMPONENT AND PRIORITY: client-libs: (P2) JDK-8206106: [solaris sparc] jck tests api/javax_print/PrintService failing (P2) JDK-8204931: Colors with alpha are painted incorrectly on Linux (P2) JDK-8200146: Remove the appletviewer launcher (P3) JDK-8205153: Delete "standard instructions" machinery in the open automated tests (P4) JDK-8180456: Apply necessary patches from both JDK and upstream (P4) JDK-8205646: Broken link in jdk.jsobject (P4) JDK-8201611: Broken links in java.desktop javadoc (P4) JDK-8180454: Build succeeds (P4) JDK-8198868: jtreg failed to clean up files after some tests (P4) JDK-8203380: Missing platform and bug information for MouseModifiersInKeyEvent test (P4) JDK-8180455: Run all tests (P4) JDK-8198693: Update ProblemsList for mac (P5) JDK-8202143: Parts of 8193435 added in merge change set. client-libs/2d: (P2) JDK-8204496: backout fix for 8203796 which was pushed under another ID (P2) JDK-8203796: Define API to support specifying ownership of print dialogs (P2) JDK-8204509: Fix compilation error in harfbuzz 1.7.6 for Solaris Developer Studio 12.6 (P2) JDK-8208466: Fix potential memory leak in harfbuzz shaping. (P2) JDK-8199530: Upgrade harfbuzz to the latest version (1.7.6) (P3) JDK-8203485: [freetype] text rotated on 180 degrees is too narrow (P3) JDK-8199870: colorimaging.md needs to remove mention of KCMS (P3) JDK-8202580: Dashed BasicStroke randomly painted incorrectly, may freeze application (P3) JDK-8199789: Emit a warning message when t2k is selected via system property (P3) JDK-8201433: Fix potential crash in BufImg_SetupICM (P3) JDK-8204929: Fonts with embedded bitmaps are not always rotated (P3) JDK-8193017: Import freetype sources into OpenJDK source tree (P3) JDK-8201240: Improve releasing native resources of BufImgSurfaceData.ICMColorData (P3) JDK-8194489: Incorrect size computation at BandedSampleModel.createDataBuffer() (P3) JDK-8154463: New failure of closed/java/awt/font/Outline/OutlineInvarianceTest.java (P3) JDK-8200129: Remove D3D Performance Counter. (P3) JDK-8200526: Test sun/java2d/marlin/ClipShapeTest.java times out (P3) JDK-8206428: Upgrade JDK11 to harfbuzz 1.8.2 (P3) JDK-8205441: Upgrade to harfbuzz 1.8.1 (P3) JDK-8153732: Windows remote printer changes do not reflect in lookupPrintServices() (P3) JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender. (P4) JDK-8196218: [linux] libfontmanager should be linked against headless awt library (P4) JDK-8204085: avoid printing uninitialized pointer in java.desktop/windows/native/libawt/java2d/windows/GDIWindowSurfaceData.cpp (P4) JDK-8201621: FreeNullICM test should be removed (P4) JDK-8202476: ImageLib is broken in 32 bit Windows (P4) JDK-8200052: libjavajpeg: Fix compile warning in jchuff.c (P4) JDK-8203355: MITSHM define guarding missing (P4) JDK-8203027: Open source tests for "java.awt.geom" (P4) JDK-8196446: sun/java2d/DirectX/StrikeDisposalCrashTest/StrikeDisposalCrashTest.java times out (P4) JDK-8196448: sun/java2d/DirectX/TransformedPaintTest/TransformedPaintTest.java times out (P4) JDK-8196449: sun/java2d/OpenGL/CustomCompositeTest.java times out (P4) JDK-8196451: sun/java2d/OpenGL/DrawBufImgOp.java times out (P4) JDK-8196452: sun/java2d/SunGraphics2D/EmptyClipRenderingTest.java times out (P4) JDK-8198613: Test cases result in failure or timeout when run with OpenGL backend (P4) JDK-8198406: Test TestAATMorxFont is unstable (P4) JDK-8204122: Update harfbuzz.md (P4) JDK-8198885: Upgrade Marlin (java2d) to 0.9.1 (P4) JDK-8204211: windows : handle potential C++ exception in GDIRenderer (P4) JDK-8187100: Wrong rendering of variation sequences client-libs/demo: (P2) JDK-8205498: Typo in fix for 8205119 breaks Solaris demo build (P3) JDK-8198990: Move SwingSet2 from closed to OpenJDK (P3) JDK-8198991: Open source Java2Demo (P4) JDK-8205136: Move StylePad demo to the open repository (P4) JDK-8205119: SwingApplet demo should be removed client-libs/java.awt: (P1) JDK-8197546: Fix for 8171000 breaks Solaris + Linux builds (P1) JDK-8201598: Fix for 8181910: Support dark title bars on macOS broke the MacOS build (P1) JDK-8196509: Linux UI applications broken by the build change for JDK-8196218 (P2) JDK-8196030: AWT Robot mouseMove fails on Windows 10 1709 with HiDPI (P2) JDK-8202478: Backout JDK-8152974 (P2) JDK-8198895: Compilation errors in java.desktop with VS 2017 (P2) JDK-8203224: java.awt.desktop.*Event classes could not be instantiated if Desktop feature is not supported (P2) JDK-8203308: Remove the appletviewer classes (P2) JDK-8195738: scroll position in ScrollPane is reset after calling validate() (P2) JDK-8198649: Switch AWT/Swing's default GTK version to 3 (P2) JDK-8204860: The frame could be resized by dragging a corner of the frame with the mouse (P2) JDK-8208353: Upgrade JDK to libpng 1.6.35 (P3) JDK-8195671: [macos] Displaying a native open dialog box raises exception (P3) JDK-8204118: [macos] Nonsensical self == [super init] in CFileDialog.m (P3) JDK-8201364: [macosx] Component.getLocation() gives inconsistent coordinate for a component at (0,0) (P3) JDK-8189201: [macosx] NotSerializableException during JFrame with MenuBar serialization (P3) JDK-8196322: [macosx] When the screen menu bar is used, clearing the default menu bar should permit AWT shutdown (P3) JDK-8154405: AccessControlException by URLPermission check (P3) JDK-8197903: Add a headless tests to the client-nightly (P3) JDK-8152974: AWT hang occurrs when sequenced events arrive out of sequence (P3) JDK-8205588: Deprecate for removal com.sun.awt.SecurityWarning (P3) JDK-8195624: Desktop API cannot be used without permission to read "os.version" (P3) JDK-8198335: java/awt/FullScreen/UninitializedDisplayModeChangeTest/UninitializedDisplayModeChangeTest.java fails in headless mode (P3) JDK-8199932: Missing copyright header in AWT source code (P3) JDK-8187635: On Windows Swing changes keyboard layout on a window activation (P3) JDK-8205324: Part of java.awt.Desktop.browse(URI) spec is outdated after support of applets was removed (P3) JDK-8189604: possible hang in sun.awt.shell.Win32ShellFolder2$KnownFolderDefinition:: (P3) JDK-8203003: Several FileDialog Modality Tests fail on Linux due to X errors (P3) JDK-8200353: Shift or Capslock not working in Textfield after accented keystrokes (P3) JDK-8200525: test java/awt/event/SequencedEvent/SequencedEventTest.java fails to compile (P3) JDK-8200149: The "com.sun.awt.AWTUtilities" class can be dropped (P3) JDK-8198606: Touch keyboard does not hide, when a text component looses focus (P3) JDK-8199748: Touch keyboard is not shown, if text component gets focus from other text component (P3) JDK-8198605: Touch keyboard is shown for a non-focusable text component (P4) JDK-8201524: [AIX] Don't link libfontmanager against libawt_headless (P4) JDK-8194327: [macos] AWT windows have incorrect main/key window behaviors (P4) JDK-7158623: [macosx] Should an unfocusable maximized Frame be resizable? (P4) JDK-8202058: A few new tests should be marked as "headful" and windows specific (P4) JDK-8202051: Address compilation warnings in libawt with VS2017 (P4) JDK-8195131: Dead code removal for changes present in JDK-8176795 (P4) JDK-8187392: Deprecated methods in the peers can be removed (P4) JDK-4475138: getBestCursorSize and XFree86 4.1.0 (P4) JDK-8196196: Headful tests should not be run in headless mode (P4) JDK-8196360: java/awt/Dialog/SiblingChildOrder/SiblingChildOrderTest.java fails (P4) JDK-8197926: java/awt/dnd/ImageTransferTest/ImageTransferTest.java doesnt close the windows in HiDPI setting (P4) JDK-8196616: java/awt/GraphicsDevice/DisplayModes/CompareToXrandrTest.java fails (P4) JDK-8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols (P4) JDK-8196438: Regression automated Test '/test/jdk/java/awt/Window/OverrideRedirectRemoved/ChildWindowProblem.java' fails (P4) JDK-8196435: Regression automated Test 'java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java' fails (P4) JDK-8171000: Robot.createScreenCapture() crashes in wayland mode (P4) JDK-8190326: Robot.mouseMove uses scaling factor of main display on unscaled second display (P4) JDK-8197808: Test java/awt/Dialog/MakeWindowAlwaysOnTop/MakeWindowAlwaysOnTop.java fails on Windows (P5) JDK-8201626: Typo in MakeWindowAlwaysOnTop test client-libs/java.awt:i18n: (P3) JDK-8201429: Support AIX Input Method Editor (IME) for AWT Input Method Framework (IMF) client-libs/java.beans: (P3) JDK-8196373: Introspector does not see overridden generic setter method client-libs/javax.accessibility: (P2) JDK-8208640: [a11y] [macos] Unable to navigate between Radiobuttons in Radio group using keyboard. (P2) JDK-8198897: Compilation errors in jdk.accessibility with VS 2017 (P3) JDK-8202768: [macos] Appkit thread slows when any Window Manager active (P3) JDK-8204862: Java atk wrapper does not load any more (P3) JDK-8197785: javax.accessibility.AccessibleBundle will reload the ResourceBundle for every call to toDisplayString client-libs/javax.imageio: (P2) JDK-8191073: JpegImageReader throws IndexOutOfBoundsException when trying to read image data from tables-only image (P3) JDK-7031957: DIB header of type BITMAPV2INFOHEADER & BITMAPV3INFOHEADER is not supported in BMPImageReader (P3) JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing (P3) JDK-8191174: PngReader throws IllegalArgumentException because ScanlineStride calculation logic is not proper (P3) JDK-8191023: PngReader throws NegativeArraySizeException when keyword length exceeds chunk size (P3) JDK-8204187: Remove proprietary JPEG code from javax.imageio (P4) JDK-6686236: GIF native IIOMetadata assumes characterCellWidth/Height as 2bytes (P4) JDK-4954348: JPGWriter.getNumThumbnailsSupported does not return -1 when passing null values (P4) JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB/Gray images (P4) JDK-6574555: PNGImageWriter incorrectly sets bKGD chunk (P4) JDK-5109146: PNGMetadata Background color initialization from standard metadata is incomplete client-libs/javax.sound: (P3) JDK-4912693: Behavior of null arguments not specified in Java Sound (P3) JDK-8202264: Race condition in AudioClip.loop() (P4) JDK-8201279: javax.sound tests should not set java.home system property (P4) JDK-8204454: Remove of sun.applet.AppletAudioClip (P4) JDK-8205456: Unification of iterations over arrays client-libs/javax.swing: (P2) JDK-8208125: Cannot input text into JOptionPane Text Input Dialog (P2) JDK-8202199: Provide public, unsupported JDK API for JavaFX/Swing interop (P2) JDK-8199441: Wrong caret position in multiline text components on Windows with a screen resolution higher than 100% (P3) JDK-8205454: & is displayed in some Swing docs (P3) JDK-8190767: [macos] if JFrame is maximized on OS X, all new JFrames will be maximized by default (P3) JDK-8199150: Accessibility issues in java.desktop (P3) JDK-8153532: Add @throws NPE javadoc to UIManager.setLookAndFeel(String) method description (P3) JDK-8206238: Aspect ratio is not maintained when Image is scaled in JEditorPane (P3) JDK-8190281: Code cleanup in src\java.desktop\share\classes\javax\swing\tree\VariableHeightLayoutCache.java (P3) JDK-8197554: Create test for SwingSet TableDemo (P3) JDK-8197948: Create test for SwingSet2 main window (P3) JDK-7007967: DefaultRowSorter: incorrect sorting due to not updating comparator cache (P3) JDK-8190192: Double click on the title bar no longer repositions the window (P3) JDK-8201552: Ellipsis in "Classical" label in SwingSet2 demo with Windows L&F at Hidpi (P3) JDK-8195095: Images are not scaled correctly in JEditorPane (P3) JDK-8197549: Implement a new method similar to waitState() on Operator which run the check on event queue (P3) JDK-8202064: Jemmy JInternalFrameOperator: Add wait for close(), activate(), resize() and move() operations (P3) JDK-8202718: Jemmy JInternalFrameOperator: Dependency with orders of Minimize, Maximize and Close buttons (P3) JDK-8191957: JFileChooser shows empty name for external drives shown under Desktop (P3) JDK-8205144: JSpinner may change the font after became visible (P3) JDK-8197482: Make Jemmy ComponentChooser lambda friendly (P3) JDK-8194767: Regression automated Test 'javax/swing/JEditorPane/6917744/bug6917744.java' fails (P3) JDK-8202696: Remove exclusion range for phonetic chars in windows fontconfig.properties (P3) JDK-8194873: right ALT key hotkeys no longer work in Swing components (P3) JDK-8189687: Swing: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows (P3) JDK-6608234: SwingWorker.get throws CancellationException (P3) JDK-8197519: Unexpected behavior of text component when entering Korean text in Ubuntu 16 (P3) JDK-8199627: Use "Per-Monitor V2" High DPI awareness for Windows 10 v1703 (P3) JDK-8171814: Wrong position of spaces in JTextField when entering Korean text on Ubuntu 16 (P4) JDK-8181910: [macos] Support dark title bars on macOS (P4) JDK-8074286: Add getSelectedIndices() to ListSelectionModel (P4) JDK-8202878: com/apple/laf/ScreenMenu/ScreenMenuMemoryLeakTest.java fails (P4) JDK-4842658: DefaultListModel and DefaultComboBoxModel should support addAll (Collection c) (P4) JDK-8198004: javax/swing/JFileChooser/6868611/bug6868611.java throws error (P4) JDK-8198005: javax/swing/JFileChooser/7199708/bug7199708.java throws error (P4) JDK-8196443: javax/swing/JList/BasicListTest.java has invalid tag (P4) JDK-8198777: JList.getPreferredScrollableViewportSize(): fix mistake in doc for height calc (P4) JDK-7108280: JList.getSelectedValuesList fails if JList.setSelectionInterval larger than list (P4) JDK-5076761: JList.setSelectedValue(null, ...) doesn't do anything (P4) JDK-8200343: Minor JViewport documentation typo (P4) JDK-8194943: Regression automated test 'open/test/jdk/javax/swing/JInternalFrame/8020708/bug8020708.java' fails (P4) JDK-8197499: RepaintManager does not increase double buffer after attaching a device with higher resolution (P4) JDK-8201328: SynthParser should use Boolean.parseBoolean (P4) JDK-8198342: Test FileSystemViewListenerLeak.java is unstable core-libs: (P2) JDK-8191913: Bump classfile version number to 55 (P2) JDK-8198302: VS2017 (C4477) java.base/windows/native/libnet/NetworkInterface_winXP.c incorrect printf format strings (P3) JDK-8199176: Accessibility issues in java.base docs (P3) JDK-8202581: failure_handler: gather more environment information on macOS (P3) JDK-8204861: fix for 8196993 has broken the build on linux (P3) JDK-8200128: Fix some "annoations" typos (P3) JDK-8200131: Improve lazy init of InetAddress.canonicalHostName and NativeObject.pageSize (P3) JDK-8207233: Minor improvements of jdk C-coding (P3) JDK-8201226: missing JNIEXPORT / JNICALL at some places in function declarations/implementations (P3) JDK-8205112: Remove non-existent modules from test/jdk/jdk/modules/etc/UpgradeableModules.java (P3) JDK-8200072: Remove un-needed qualified export from java.base to java.desktop (P3) JDK-8200121: Remove unused qualified exports in java.base (P3) JDK-8202997: Split test/jdk/:tier1 to enable better parallel execution (P3) JDK-8201609: Split test/jdk/:tier2 to enable better parallel execution (P3) JDK-8177680: Umbrella: JDK 11 terminal deprecations (P3) JDK-8201394: Update java.se module summary to reflect removal of java.se.ee module (P3) JDK-8194070: Update various tests to pass under JDK 11 (P3) JDK-8193854: Version increment for JDK 11 (P4) JDK-8202763: failure_handler: list open files for macOS (P4) JDK-8199616: Fix @module declarations in tier1 tests (P4) JDK-8202544: Hide unused exports in libzip (P4) JDK-8197418: Move java/util/RandomAccess/ tests into OpenJDK (P4) JDK-8199464: Remove remaining vestiges of Java_sun_reflect_Reflection_getCallerClass (P4) JDK-8193033: remove terminally deprecated sun.misc.Unsafe.defineClass (P4) JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass (P4) JDK-8198656: Update copyright to 2018 (P4) JDK-8198645: Use System.lineSeparator() instead of getProperty("line.separator") (P5) JDK-8198539: Cleanup of unused imports in java/util/jar/Attributes.java (java.base) and JdpController.java (jdk.management.agent) core-libs/java.io: (P2) JDK-8202105: Console echo is disabled when exiting jshell (P2) JDK-8204930: Reader:nullReader() spec does not match the behavior (P3) JDK-8183554: Add constructors with Charset parameter for FileReader and FileWriter (P3) JDK-8202290: AtomicAppend tests fail on macOS 10.13 ("High Sierra") (P3) JDK-8203369: Check for both EAGAIN and EWOULDBLOCK error codes (P3) JDK-8194750: Console.readPassword does not save/restore tty settings (P3) JDK-8194154: System property user.dir should not be changed (P3) JDK-8202062: test/jdk/java/io/FileOutputStream/AtomicAppend.java failed (P3) JDK-8202292: test/jdk/java/io/FileOutputStream/UnreferencedFOSClosesFd.java fails with "raw fd count wrong" (P4) JDK-8139206: Add InputStream readNBytes(int len) (P4) JDK-8196298: Add null Reader and Writer (P4) JDK-8202324: Avoid loading FileInput-/OutputStream$AltFinalizer (P4) JDK-8180410: ByteArrayOutputStream should not throw IOExceptions (P4) JDK-8198997: Cache normalized/resolved user.dir property (P4) JDK-8204663: clean up remaining native parts after JDK-8187631 (P4) JDK-8189330: Cleanup FileDescriptor implementation (P4) JDK-8202284: FileChannel and FileOutpuStream variants of AtomicAppend should pass silently on macOS >= 10.13 (P4) JDK-8182684: Further clarify InputStream#available() (P4) JDK-8194649: Minor cleanup of parameter checking in ByteArrayOutputStream and ObjectInputStream (P4) JDK-8193832: Performance of InputStream.readAllBytes() could be improved (P4) JDK-8200449: ReadAllReadNTransferTo fails occasionally (P4) JDK-8197538: Remove mention of hotjava paths in MimeTable.java (P4) JDK-8199470: Remove unused property file.encoding.pkg (P4) JDK-8202076: test/jdk/java/io/File/WinSpecialFiles.java on windows with VS2017 (P4) JDK-8193861: Typos in API documentation of File.toPath() and InetSocketAddress.getAddress() (P4) JDK-8205416: windows: fix checking of CloseHandle return code in Java_java_io_FileCleanable_cleanupClose0 (P5) JDK-4358774: Add null InputStream and OutputStream (P5) JDK-8180451: ByteArrayInputStream should override readAllBytes, readNBytes, and transferTo core-libs/java.io:serialization: (P2) JDK-8206865: RMI activation tests fail with InvalidClassException (P3) JDK-8203368: ObjectInputStream filterCheck method throws NullPointerException (P3) JDK-8197595: Serialization javadoc should link to security best practices core-libs/java.lang: (P2) JDK-8208164: (str) improve specification of String::lines (P2) JDK-8182490: JEP 327: Unicode 10 (P2) JDK-8194879: Runtime.Version parses string which does not conform to spec without throwing IAE (P3) JDK-7183985: (ann) Class.getAnnotation() throws an ArrayStoreException when the annotation class not present (P3) JDK-8197812: (ref) Data race in Finalizer (P3) JDK-8201793: (ref) Reference object should not support cloning (P3) JDK-8193780: (ref) Remove the undocumented "jdk.lang.ref.disableClearBeforeEnqueue" system property (P3) JDK-8196740: Character.digit(int,int) returns wrong value for out of range radix (P3) JDK-8205533: Class.getPackage() fails with InternalError if class is defined to the boot class loader but module is not in the boot layer (P3) JDK-8198653: ClassLoader::getSystemClassLoader throws InternalError when called after shutdown (P3) JDK-8200478: For boxing conversion javac uses Long.valueOf which does not guarantee caching according to its javadoc (P3) JDK-8197930: JNI exception pending in initializeEncoding of jni_util.c (P3) JDK-8066709: Make some JDK system properties read only (P3) JDK-8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer (P3) JDK-8199800: Optimize Boolean.parseBoolean(String) (P3) JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit (P3) JDK-8200122: Remove unused field Thread.threadQ (P3) JDK-8200123: Replace Thread.init with telescoping constructor (P3) JDK-8205623: Replace use of Class::getPackage with Class::getPackageName (P3) JDK-8197594: String#repeat (P3) JDK-8198955: String#repeat loop optimization (P3) JDK-8200436: String::isBlank (P3) JDK-8200380: String::lines (P3) JDK-8200377: String::strip, String::stripLeading, String::stripTrailing (P3) JDK-8200372: String::trim JavaDoc should clarify meaning of space (P3) JDK-8191410: Unicode 10.0.0 support (P4) JDK-8204565: (spec) Document java.{vm.}?specification.version system properties' relation to $FEATURE (P4) JDK-4993841: (str) java.lang.Character should have a toString(int) method (P4) JDK-8200706: Better cleanup for open/test/jdk/java/lang/ProcessBuilder/DestroyTest.java (P4) JDK-8191170: Clarify if java.class.path can be undefined (P4) JDK-8196127: Dead code in VersionProps.java.template (P4) JDK-8201246: Export native function to set platform encoding (P4) JDK-8200664: fix broken links in java.base docs (P4) JDK-8203352: Improve java implementation of Integer/Long.numberOfLeadingZeros (P4) JDK-8189230: JDK method:java.lang.Integer.numberOfLeadingZeros(int) can be optimized (P4) JDK-8198970: jnu_util.c compilation error on Solaris (P4) JDK-8202771: Migrate Unicode character tests to JDK Repo. (P4) JDK-8195981: Move some tests to OpenJDK for jdk_lang test group (P4) JDK-8196331: Optimize Character.digit for latin1 input (P4) JDK-8199843: Optimize Integer/Long.highestOneBit() (P4) JDK-8198989: Provide more diagnostic IAE messages (P4) JDK-8204243: remove Thread.destroy() and Thread.stop(Throwable) (P4) JDK-8193818: Remove unused single_step field from java.lang.Thread (P4) JDK-8204377: Rename Object#wait parameter name from "timeout" to "timeoutMillis" (P4) JDK-8198441: Replace native Runtime::runFinalization0 method with shared secrets (P4) JDK-8196668: revisit test SunPackageAccess and GrantedSunPackageAccess (P4) JDK-8198697: Simplify initialization of platform encoding (P4) JDK-8199756: Simplify language, country, script, and variant property initialization (P4) JDK-8203327: Small cleanups in java.lang.ref (P4) JDK-8200172: String.split non-positive term incorrect use (P4) JDK-8198841: Thread.interrupt should set interrupt status while holding blockerLock (P4) JDK-8203474: Update description of "Cyrillic Supplementary" block name in Character.UnicodeBlock class. (P4) JDK-8199420: Update javadoc tags in java.lang.System and related (P4) JDK-8199465: {@docRoot} references need to be updated to reflect new module/package structure (P5) JDK-8200696: Optimal initial capacity of java.lang.Class.enumConstantDirectory (P5) JDK-8200788: Optimal initial capacity of java.lang.VarHandle.AccessMode.methodNameToAccessMode core-libs/java.lang.invoke: (P2) JDK-8198492: Bootstrapping java.lang.invoke can cause deadlock after JDK-8198418 (P2) JDK-8197944: Condy tests fails on Windows (P2) JDK-8187742: Minimal set of bootstrap methods for dynamic constants (P2) JDK-8198375: Passing 'null' value to lookup param of ConstantBootstraps.invoke does not throw NullPointerException (P2) JDK-8197945: Qurarantine failing condy tests (P3) JDK-8198889: Clarify the throwing of exceptions from ConstantBootstraps.invoke (P3) JDK-8145371: ClassCastException thrown in LambdaFormEditor.getInCache (P3) JDK-8185992: Development of Dynamic constants in the JVM (P3) JDK-8196960: Exceptions in ConstantBootstrapsTest.java on SPARC (P3) JDK-8194554: filterArguments runs multiple filters in the wrong order (P3) JDK-8203886: Invoke LambdaMetafactory::altMetafactory exactly from the BootstrapMethodInvoker (P3) JDK-8198418: Invoke LambdaMetafactory::metafactory exactly from the BootstrapMethodInvoker (P3) JDK-8207027: Lookup.accessClass fails for an array type in the same package when assertions are enabled (P3) JDK-8202922: Method reference identity is broken by serialization (P3) JDK-8199875: Require first parameter type of a condy bootstrap to be Lookup (P3) JDK-8200167: Validate more special case invocations (P4) JDK-8195694: ConstantBootstraps.invoke does not preserve variable arity (P4) JDK-8199471: Enable generation of callSiteForms at link time (P4) JDK-8199453: Enable link-time generation of constructor forms (P4) JDK-8195850: Improve startup of code to pull arguments from BootstrapMethodInvoker (P4) JDK-8204194: Lazily create MethodHandleImpl$AsVarargsCollector.asCollectorCache (P4) JDK-8195650: Method references to VarHandle accessors (P4) JDK-8177276: MethodHandles.insertArguments doesn't specify IllegalArgumentException on index mismatch (P4) JDK-8198755: Reduce cost of InvokerBytecodeGenerator::isStaticallyInvocable/-Nameable (P4) JDK-8200289: Reduce number of exceptions created when calling Lookup::canBeCached (P4) JDK-8200238: Reduce number of exceptions created when calling MemberName$Factory::resolveOrNull (P4) JDK-8198888: Reduce string allocation churn in InvokerBytecodeGenerator (P4) JDK-8202184: Reduce time blocking the ClassSpecializer cache creating SpeciesData (P4) JDK-8198523: Refactor BootstrapMethodInvoker to further avoid runtime type checks (P4) JDK-8195717: test java/lang/invoke/MethodHandlesTest timed out running testAsCollector1 (P4) JDK-8196533: Update CondyNestedTest.java to compile jcod file (P4) JDK-8202548: Use reservation Object when creating SpeciesData (P5) JDK-8198831: Lazy initialization of ValueConversions MethodHandles core-libs/java.lang.module: (P3) JDK-8200134: Improve ModuleHashesBuilder (P3) JDK-8197532: Re-examine policy for the default set of modules when compiling or running code on the class path (P3) JDK-8200127: Replace collection.stream().forEach() with collection.forEach() (P4) JDK-8194644: Typo in ModuleDescriptor.read javadoc core-libs/java.lang:class_loading: (P3) JDK-8200125: Fix some classloader/module typos (P3) JDK-8199947: Rename HTML element id in ClassLoader javadoc to avoid name conflict with private elements (P4) JDK-8198485: Simplify a URLClassPath constructor (P4) JDK-8198482: The URLClassPath field "urls" should be renamed to "unopenedUrls" (P4) JDK-8198484: URLClassPath should use an ArrayDeque instead of a Stack (P5) JDK-8198481: Coding style cleanups for src/java.base/share/classes/jdk/internal/loader (P5) JDK-8198480: Improve ClassLoaders static init block core-libs/java.lang:reflect: (P4) JDK-8188240: (proxy) proxy generator should only inspect instance methods (P4) JDK-8187123: (reflect) Class#getCanonicalName and Class#getSimpleName is a part of performance issue (P4) JDK-8199862: Examine ProxyBuilder::referencedTypes startup cost (P4) JDK-8202113: Reflection API is causing caller classes to leak (P4) JDK-8205003: Replaced selected link tags with linkplain in java.lang.Class (P5) JDK-8199865: Avoid initializing ShortCache in ProxyGenerator (P5) JDK-8198669: Refactor annotation array value parsing to reduce duplication core-libs/java.math: (P4) JDK-8199258: BigInteger.bitLength() should explicitly specify behavior when the value is zero (P4) JDK-8202563: BigInteger/BigDecimal not immune to overflow, contrary to spec. core-libs/java.net: (P2) JDK-8208391: Differentiate response and connect timeouts in HTTP Client API (P2) JDK-8206001: Enable TLS1.3 by default in Http Client (P2) JDK-8197564: HTTP Client implementation (P2) JDK-8207966: HttpClient response without content-length does not return body (P2) JDK-8181784: JEP 321: HTTP Client (P2) JDK-8208691: Tighten up jdk.includeInExceptions security property (P2) JDK-8200304: TwoStacksPlainDatagramSocketImpl and socket cleaner (P2) JDK-8198803: URLClassLoader does not specify behavior when URL array contains null (P3) JDK-8201186: Add BodyHandler>> (P3) JDK-8194298: Add support for per Socket configuration of TCP keepalive (P3) JDK-8207265: Bad HTML in {@link} in HttpResponse.BodySubscribers.ofPublisher (P3) JDK-8207846: Generalize the jdk.net.includeInExceptions security property (P3) JDK-8204679: HTTP Client refresh (P3) JDK-8198947: HttpClient fails to send successive POST requests under HTTP/2 (P3) JDK-8203427: HttpClient HTTP/1.1 could be more lenient and accept LF as well as CRLF as header separator. (P3) JDK-8203882: HttpClient throws IOException when receiving 401/407 with no WWW-Authenticate/Proxy-Authenticate header (P3) JDK-8203771: It's not possible to override default user agent with java.net.http HTTPClient (P3) JDK-8194729: Java 9's HttpClient doesn't allow custom "Authorization" headers (P3) JDK-8196775: java/net/Socket/asyncClose/Race.java failed intermittently on Windows with ConnectException: Connection refused (P3) JDK-8203297: java/net/URL/OpenStream.java fails intermittently (P3) JDK-8207960: Non-negative WINDOW_UPDATE increments may leave the stream window size negative (P3) JDK-8200181: Remove superflous non-IPv4 code from Java_java_net_TwoStacksPlainSocketImpl_socketListen (P3) JDK-8205945: Revert unintended changes to make/gensrc/Gensrc-jdk.hotspot.agent.gmk (P3) JDK-8202423: Small HTTP Client refresh (P3) JDK-8207959: The initial value of SETTINGS_MAX_CONCURRENT_STREAMS should have no limit (P3) JDK-8195059: Update java.net Socket and DatagramSocket implementations to use Cleaner (P3) JDK-8199135: Validate that method names are tokens (P3) JDK-8192797: Websocket fails to handle server requests immediately after wss connection obtained (P3) JDK-8205342: windows : potential memleaks in getAdapter(s) in NetworkInterface_winXP.c (P4) JDK-8204233: Add configurable option for enhanced socket IOException messages (P4) JDK-8198358: Align organization of TwoStacksPlainSocketImp with DualStackPlainSocketImpl [win] (P4) JDK-8200719: Cannot connect to IPv6 host when exists any active network interface without IPv6 address (P4) JDK-8202181: Correctly specify size of hostname buffer in Unix Inet*AddressImpl_getLocalHostName implementations (P4) JDK-8205959: Do not restart close if errno is EINTR (P4) JDK-8199730: Examine HttpClient HeapByteBuffer allocation (P4) JDK-8193504: HttpClient very slow if downloading a 160M file with TLS (P4) JDK-8169358: httpserver does not close connections when RejectedExecutionException occurs (P4) JDK-8199437: Improve diagnostic system assertion message in com.sun.net.httpserver impl (P4) JDK-8201369: Inet4AddressImpl_getLocalHostName reverse lookup on Solaris only (P4) JDK-8205397: InetAddress has wrong declaration for readObjectNoData (P4) JDK-8144300: Java does not honor http.nonProxyHosts value having wildcard * both at end and start (P4) JDK-8199683: jdk.incubator.http.HttpClient/jdk.incubator.http.HttpRequest change encoding of URI (P4) JDK-8201510: Merge TwoStacksPlainSocketImpl into DualStackPlainSocketImpl [win] (P4) JDK-8197849: Misc improvements to jar resource handling (P4) JDK-8203937: Not possible to read data from socket after write detects connection reset (P4) JDK-8194676: NullPointerException is thrown if ipaddress is not set. (P4) JDK-8199329: Remove code that attempts to read bytes after connection reset reported (P4) JDK-8058965: Remove IPv6 support from TwoStacksPlainSocketImpl [win] (P4) JDK-8202154: Remove unused code in java.base/windows/native/libnet (P4) JDK-8202091: Rename DualStackPlainSocketImpl to PlainSocketImpl [win] (P4) JDK-8196851: SplitResponseSSL test fails on Solaris because MockServer::write gets SocketException (P4) JDK-8163291: Support HTTPS tunnelling through authenticating proxies (P4) JDK-8199851: The jdk.incubator.http.HttpClient sends multiple Cookie headers with HTTP/1.1 (P5) JDK-8201545: InetAddress.getByName/getAllByName should clarify empty String behavior core-libs/java.nio: (P2) JDK-8199773: (bf) XXXBuffer:compareTo method is not working as expected (P2) JDK-8202261: (fc) FileChannel.map and RandomAccessFile.setLength should not preallocate space (P2) JDK-8198928: (so) SocketChannel connect may deadlock if closed at around same time that connect fails (P2) JDK-8207235: ManagementFactory.getPlatformMXBeans(BufferPoolMXBean.class) throws NPE (P3) JDK-8196787: (ch) Moving network channels to use j.u.c locks (P3) JDK-8198562: (ch) Separate blocking and non-blocking code paths (part 1) (P3) JDK-8198754: (ch) Separate blocking and non-blocking code paths (part 2) (P3) JDK-8205612: (fc) Files.readAllBytes fails with ClosedByInterruptException when interrupt status set (P3) JDK-8194746: (fs) Add equivalents of Paths.get to Path interface (P3) JDK-8206448: (fs) Extended attributes assumed to be enabled on ext3 (lnx) (P3) JDK-8205058: (fs) Files read/writeString should throw CharacterCodingException instead of IOException with an IllegalArgumentException as cause (P3) JDK-8165852: (fs) Mount point not found for a file which is present in overlayfs (P3) JDK-8200458: (se) Readiness information previously recorded in the ready set not preserved (P3) JDK-8201474: (so) Socket adaptor connect(InetAddress, timeout) succeeds when connection fails (P3) JDK-8198372: API to create a SelectableChannel to a FileDescriptor (P3) JDK-8193802: NullPointerException from JarFileSystem.getVersionMap() (P3) JDK-8200243: System error message is decoded as invalid encoding in Windows. (P3) JDK-8202397: Typo in X-Buffer javadoc (P3) JDK-8193085: Vectorize the nio Buffer equals and compareTo implementations (P4) JDK-8202216: (bf) Add Buffer mismatch() (P4) JDK-8191416: (bf) DirectByteBuffer extends MappedByteBuffer, confuses instanceof tests (P4) JDK-8166253: (ch) FileLock object can get GC'd and result in unexpected release of file lock (P4) JDK-8196956: (ch) More channels cleanup (P4) JDK-8144672: (ch) PipeImpl should use localhost instead of loopback address (P4) JDK-8198753: (dc) DatagramChannel throws unspecified exceptions (P4) JDK-8201276: (fs) Add methods to Files for reading/writing a string from/to a file (P4) JDK-8204915: (fs) Add some print diagnostics to java/nio/file/Files/CopyAndMove.java (P4) JDK-8009632: (fs) FileStore.supportsFileAttributeView does not detect user_xattr enabled on ext4 (P4) JDK-8205062: (fs) Improve some print diagnostics in java/nio/file/Files/CopyAndMove.java (P4) JDK-8204576: (fs) java/nio/file/Files/CopyAndMove.java does not set isUnix = true on macOS (P4) JDK-8199124: (fs) Reduce allocation for file system methods that are invoked with no open options (P4) JDK-8201315: (se) Allow SelectableChannel.register to be invoked while selection operation is in progress (P4) JDK-8197498: (se) kevent polling should ignore signal interrupt (EINTR) (P4) JDK-8199611: (se) Minor selector implementation clean-up (P4) JDK-8199791: (se) More Selector cleanup, part 1 (P4) JDK-8200179: (se) More Selector cleanup, part 2 (P4) JDK-8200257: (se) More Selector cleanup, part 3 (P4) JDK-8199433: (se) select(Consumer action) as alternative to selected-key set (P4) JDK-6350055: (se) SelectionKey.interestOps variants to atomically update interest ops (P4) JDK-8200583: (se) Selector clean-up, part 4 (P4) JDK-8199015: (se) SocketChannelImpl.translateXXXOps access channel state without synchronization (P4) JDK-8203059: (so) Closing a socket channel registered with Selector and with SO_LINGER set to 0 does not reset connection (P4) JDK-8199120: (so) SocketChannelImpl read/write don't need stateLock when channel is configured non-blocking (P4) JDK-8203766: Add some instrumentation to jdk/java/nio/channels/Selector/RacyDeregister.java (P4) JDK-8207023: Add trace info to java/nio/channels/Selector/RegisterDuringSelect.java (P4) JDK-8201494: Avoid early initialization of java.nio.Bits (P4) JDK-8202788: Explicitly reclaim cached thread-local direct buffers at thread exit (P4) JDK-8201407: Files.move throws DirectoryNotEmptyException when moving directory across file system (P4) JDK-8200256: java/nio/channels/AsynchronousChannelGroup/Basic.java fails intermittently (P4) JDK-8203765: java/nio/channels/Selector/SelectAndClose: add some prints and @intermittent tag (P4) JDK-8179307: Java_sun_nio_ch_KQueue_keventPoll throws an exception with "kqueue failed" instead of "kevent poll failed". (P4) JDK-8205641: Make java/nio/channels/Selector/RacyDeregister.java noisier and flush after prints (P4) JDK-8202481: RegisterDuringSelect.java fails with java.util.concurrent.ExecutionException: java.nio.channels.ClosedSelectorException (P4) JDK-8196535: Remove support for pre-Java 6 non-JVM-wide file locking (P4) JDK-8193842: Replace Files.copy(InputStream,OutputStream) with InputStream.transferTo(OutputStream) (P4) JDK-8199462: Use Reference.reachabilityFence in direct ByteBuffer methods core-libs/java.nio.charsets: (P3) JDK-8166339: Code conversion working behavior was changed for x-IBM834 (P3) JDK-8202329: Codepage mappings for IBM-943 and Big5 (aix) (P4) JDK-8201540: [AIX] Extend the set of supported charsets in java.base (P4) JDK-8187653: Lock in CoderResult.Cache becomes performance bottleneck (P4) JDK-8196211: Move two sun/nio/cs tests into OpenJDK (P4) JDK-8201179: Regression due loading java.nio.charset.StandardCharsets during bootstrap (P4) JDK-8198966: To make CoderResult.Cache.cache final and allocate it eagerly. (P5) JDK-8201178: Remove sun.nio.cs.FastCharsetProvider core-libs/java.rmi: (P3) JDK-8201610: Broken link on the page api/java.rmi/java/rmi/server/UnicastRemoteObject.html (P3) JDK-8188897: java/rmi/registry/reexport/Reexport.java failed with Port already in use (P4) JDK-8202291: java/rmi/Naming/LookupIPv6.java failed with Connection refused (P4) JDK-8202756: move FilterUSRTest.java to openJDK core-libs/java.sql: (P3) JDK-8201608: Broken links on page docs/api/java.sql.rowset/javax/sql/rowset/package-summary.html core-libs/java.text: (P3) JDK-8198821: fix test methods access for test java/text/Normalizer/NormalizerAPITest.java (P3) JDK-8200364: Remove unnecessary boxing via primitive wrapper valueOf(String) methods (P4) JDK-8146656: [Doc] Wrong Months Array for DateFormatSymbols (P4) JDK-8196759: Move two java/text/Normalizer tests into OpenJDK (P4) JDK-8203487: Typo in ICUBinary.java: s/Magin/Magic/ (P4) JDK-8200888: typo in name of exception in @throws core-libs/java.time: (P2) JDK-8195837: (tz) Upgrade time-zone data to tzdata2018c (P3) JDK-8206980: DateTimeFormatter throws parsing a valid string depending on the locale (P3) JDK-8042131: DateTimeFormatterBuilder Mapped-values do not work for JapaneseDate (P3) JDK-8204342: Methods in java.time's TCKZoneRules OpenJDK test miss @Test annotation (P4) JDK-8200359: (tz) Upgrade time-zone data to tzdata2018d (P4) JDK-8203233: (tz) Upgrade time-zone data to tzdata2018e (P4) JDK-8194412: Adding 256 units of IsoFields.QUARTER_YEARS broken (P4) JDK-8202582: DateTimeFormatterBuilder.parseOffsetBased unnecessarily calls toString() (P4) JDK-8201507: Generate alias entries in j.t.f.ZoneName from tzdb at build time (P4) JDK-8204444: java.time cleanup (P5) JDK-8196609: Improve javadoc for java.time.Instant.getEpochSecond core-libs/java.util: (P2) JDK-8198899: Compilation errors in java.prefs with VS 2017 (P2) JDK-8197988: T2 test javax/net/ssl/interop/ClientHelloChromeInterOp.java failed after JDK-8164278 (P3) JDK-8184693: (opt) add Optional.isEmpty (P3) JDK-8205194: Improve the Array Comparison when there is mismatch at first element. (P3) JDK-8176379: java.util.Base64 mime encoder behaves incorrectly if initialized with a line length of size 1-3 (P3) JDK-8164278: java.util.Base64.EncOutputStream/DecInputStream is slower than corresponding version in javax.mail package (P3) JDK-8201766: Mark TimSortStackSize2.java as intermittently failing (P3) JDK-8202398: Optimize Arrays.deepHashCode (P3) JDK-8204172: Predicate::not should explicitly mention "NullPointerException - if target is null" (P3) JDK-8199435: Unsafe publication of java.util.Properties.map (P4) JDK-8195649: (opt) reorganize tests for java.util.Optional (P4) JDK-8157903: (prop) move Properties tests into OpenJDK (P4) JDK-8203279: Faster rounding up to nearest power of two (P4) JDK-8204229: Formatter and String.format ignore the width with the percent modifier (%5%) (P4) JDK-8204539: improve error messages in matchJavaTZ [windows] (P4) JDK-8170159: Improve the performance of BitSet traversal (P4) JDK-8196869: Optimize Locale creation (P4) JDK-8050818: Predicate::not - provide an easier way to negate a predicate (P4) JDK-8201634: Random seedUniquifier uses incorrect LCG core-libs/java.util.concurrent: (P3) JDK-8191483: AbstractQueuedSynchronizer cancel/cancel race (P3) JDK-8200520: forkjoin tasks interrupted after shutdown (P3) JDK-8205576: forkjoin/FJExceptionTableLeak.java fails "AssertionError: failed to satisfy condition" (P3) JDK-8200258: Improve CopyOnWriteArrayList subList code (P3) JDK-8193300: Miscellaneous changes imported from jsr166 CVS 2018-01 (P3) JDK-8195590: Miscellaneous changes imported from jsr166 CVS 2018-02 (P3) JDK-8197531: Miscellaneous changes imported from jsr166 CVS 2018-04 (P3) JDK-8201386: Miscellaneous changes imported from jsr166 CVS 2018-05 (P3) JDK-8190324: ThreadPoolExecutor should not specify a dependency on finalization (P4) JDK-8204375: Add TimeUnit#convert(Duration) (P4) JDK-8202373: Forcing eager initialization of CHM$ReservationNode avoids deoptimization (P4) JDK-8203681: Miscellaneous changes imported from jsr166 CVS 2018-06 (P4) JDK-8202422: value of 'sizeCtl' in ConcurrentHashMap varies with the constructor called core-libs/java.util.jar: (P3) JDK-8200530: '\r' is not supported as "newline" in java.util.jar.Manifest. (P3) JDK-8200310: Avoid charset lookup machinery in java.nio.charset.StandardCharsets (P3) JDK-8200116: ConstructInflaterOutput, ConstructDeflaterInput still spamming test logs (P3) JDK-8204494: Fix for JDK-8200530 triggered regression: fails to handle the case that \r\n is at the 8192 boundary (P3) JDK-8200124: Various cleanups in jar/zip (P4) JDK-8203839: API clarification: versioned jar entry verification in multi-release jar file (P4) JDK-6805750: Improve handling of Attributes.Name (P4) JDK-6341887: Inflater.setInput(), Inflater.inflate() can't handle ByteBuffer (P4) JDK-6372077: JarFile.getManifest() should handle manifest attribute name 70 bytes (P4) JDK-8197989: java/util/zip/ZipFile/TestCleaner.java failed with "cleaner failed to clean zipfile" (P4) JDK-8201615: Links to javadoc should be corrected in Jar file spec. (P4) JDK-8201443: NoSuchMethodException JarFile.open when jar file is used in classpath (P4) JDK-8203328: Rename EFS in java.util.zip internals to something meaningful (P4) JDK-8196987: Resolve disabled warnings for libzip (P5) JDK-8202719: Use Collections.emptyEnumeration where possible core-libs/java.util.logging: (P2) JDK-8195096: Exception printed on console with custom LogManager on starting Apache Tomcat (P2) JDK-8198490: java/util/logging/TestLogConfigurationDeadLock.java timed out. (P3) JDK-8196768: RootLoggerHandlers fails when source tree is read-only core-libs/java.util.regex: (P3) JDK-8184692: add Pattern.asMatchPredicate (P3) JDK-8164781: Pattern.asPredicate specification is incomplete (P4) JDK-8190417: java.util.regex.Matcher method doc points to incorrect links (P4) JDK-8194667: Regex: Serialization doesn't work with match flags (P5) JDK-8179608: Error in comment in Pattern.java (P5) JDK-8197462: Inconsistent exception messages for invalid capturing group names core-libs/java.util.stream: (P4) JDK-8134459: java/util/stream/test/org/openjdk/tests/java/util/stream/WhileOpTest.java timed out core-libs/java.util:collections: (P3) JDK-8060192: Add default method A[] Collection.toArray(IntFunction generator) (P3) JDK-8201518: add test for randomized iteration order of unmodifiable Set and Map (P3) JDK-8205184: Delegating Iterator implementations that don't delegate forEachRemaining() (P3) JDK-8203864: Execution error in Java's Timsort (P3) JDK-8196207: Inefficient ArrayList.subList().toArray() (P3) JDK-8203184: List.copyOf() fails to copy sublists (P3) JDK-8191418: List.of().indexOf(null) doesn't throw NullPointerException (P3) JDK-8197893: Mistaken type check in CheckedEntrySet.toArray (P3) JDK-8202685: Optimize ArrayList subList replaceAll (P3) JDK-8193128: Reduce number of implementation classes returned by List/Set/Map.of() (P3) JDK-8203670: unmodifiable List iterator() implementations should not be ListIterators (P4) JDK-8196340: (coll) Examine overriding inherited methods in ArrayList and ArrayList.SubList (P4) JDK-8200728: Docs (Comparison of Stack and Deque methods) for Deque is not correct (P4) JDK-8201650: Move iteration order randomization of unmodifiable Set and Map to iterators core-libs/java.util:i18n: (P2) JDK-8209047: "Illegal pattern character 'B'" IllegalArgumentException with Burmese locales (P2) JDK-8202088: Japanese new era implementation (P2) JDK-8199647: java/util/Locale/SoftKeys.java fails with OutOfMemoryError again (P2) JDK-8207152: Placeholder for Japanese new era should be two characters (P3) JDK-8181157: CLDR Timezone name fallback implementation (P3) JDK-8193767: Improve javadoc in ResourceBundle working with modules (P3) JDK-8193552: ISO 4217 Amendment #165 Update (P3) JDK-8202026: ISO 4217 Amendment #166 Update (P3) JDK-8204269: ISO 4217 Amendment #167 Update (P3) JDK-8206886: Java does not set the default format locale correctly on mac10.13 (P3) JDK-8206965: java/util/TimeZone/Bug8149452.java failed on de_DE and ja_JP locale. (P3) JDK-8179071: Month value is inconsistent between CLDR and Java in some special locales (P3) JDK-8189784: Parsing with Java 9 AKST timezone returns the SystemV variant of the timezone (P3) JDK-8204603: Short week days, NaN value and timezone name are inconsistent between CLDR and Java in zh_CN, zh_TW locales. (P3) JDK-8198228: Spec clarification: j.u.Locale.getDisplayName() (P3) JDK-8199009: test/jdk/java/util/Locale/SoftKeys.java fails with OutOfMemoryError (P3) JDK-8180591: Timezone displayname is incorrect for some Timezone ID (P3) JDK-8202537: Update CLDR to version V33 (P3) JDK-8205158: Update the .md files for 3rd party software Unicode 10.0, ICU 60.2, and CLDR v33 (P3) JDK-8203872: Upgrading JDK with latest available LSR data from IANA. (P3) JDK-8203324: Use out of scope in getMacOSXLocale of java_props_macosx.c:120 (P4) JDK-8204938: Add a test case to automatically check the updated LSR data (P4) JDK-8194148: bcp47u/SymbolsTests.java and FormatTests.java fail on th_TH locale (P4) JDK-8199672: ClassCastException is thrown by java.util.Formatter when an NumberFormatProvider SPI is used. (P4) JDK-8196399: Formatting a decimal using locale-specific grouping separators causes ArithmeticException (division by zero). (P4) JDK-8190904: Incorrect currency instance returned by java.util.Currency.getInstance() (P4) JDK-8060094: java/util/Formatter/Basic.java failed in tr locale (P4) JDK-8197829: Optimize CLDRCalendarDataProviderImpl::retrieveInteger (P4) JDK-8198385: Remove property sun.locale.formatasdefault (P4) JDK-8202484: Unused field in TimeZone core-libs/javax.lang.model: (P3) JDK-8187950: javax.lang.model APIs throws CompletionFailure or a subtype of CompletionFailure. (P4) JDK-8193291: Add SourceVersion.RELEASE_11 (P4) JDK-8202334: Update javax.lang.model.util visitors for 11 (P4) JDK-8196551: Update TestSourceVersion.java to be robust across version changes core-libs/javax.naming: (P4) JDK-8198931: remove java.xml.bind module dependency for com/sun/jndi tests core-libs/javax.script: (P3) JDK-8011697: ScriptEngine "js" randomly means either "rhino" or "nashorn", but should instead select one (P4) JDK-8198816: AbstractScriptEngine.getScriptContext creation of SimpleScriptContext is inefficient core-libs/jdk.nashorn: (P3) JDK-8200215: 17th loop of "let foo = ''"; throws ReferenceError (P3) JDK-8204492: Add deprecation annotation to Nashorn APIs and warning to nashorn, jjs (P3) JDK-8194985: JavaAdapterBytecodeGenerator passes invalid type descriptor to ASM (P3) JDK-8203814: javac --release=8 "cannot find symbol" for NashornException.getEcmaError() (P3) JDK-8202786: JEP 335: Deprecate the Nashorn JavaScript Engine (P3) JDK-8199869: Missing copyright headers in nashorn source code (P3) JDK-8200716: Object propertyIsEnumerable buggy behavior on short integer-string key (P3) JDK-8193371: Use Dynalink REMOVE operation in Nashorn (P4) JDK-8204290: Add check to limit number of capture groups (P4) JDK-8157251: BeanLinker relinks array length operations for array types (P4) JDK-8204288: Matching the end of a string followed by an empty greedy regex and a word boundary fails (P4) JDK-8199443: Nashorn multithread bottleneck with "use strict" (P4) JDK-8199236: Nashorn uses deprecated HTML tags in Javadoc (P4) JDK-8201466: Nashorn: defineProperty setters/getters on prototype object ignored with numeric property names (P4) JDK-8195829: Parsing a nameless ES6 class results in a thrown NullPointerException. (P4) JDK-8193295: Remove COMMALEFT from Nashorn tokens (P5) JDK-8147614: add jjs test for -t option core-svc: (P3) JDK-8203357: Container Metrics (P3) JDK-8206243: java -XshowSettings fails if memory.limit_in_bytes overflows LONG.max core-svc/debugger: (P2) JDK-8198808: jdi tests failing after JDK-8198484 (P2) JDK-8202155: quarantine test com/sun/jdi/JdbExprTest.sh on all platforms (P3) JDK-8187448: 360 doc issues in jdwp-protocol.html (P3) JDK-8193150: Create a jtreg version of the test from JDK-8187143 (P3) JDK-8206145: dbgsysSocketClose - do not restart close if errno is EINTR [linux] (P3) JDK-8205608: Fix 'frames()' in ThreadReferenceImpl.c to prevent quadratic runtime behavior (P3) JDK-8191948: jdb error: InvalidTypeException: Can't assign double[][][] to double[][][] (P3) JDK-8185803: JdbExprTest.sh fails in JDK10-hs nightly due to "Name unknown: java.lang.Long.MAX_VALUE " (P3) JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW() (P4) JDK-8207261: [Graal] JDI and JDWP tests that consume all memory should be filtered out to not run with Graal (P4) JDK-8203809: [Graal] JDI tests fail with: JDITestRuntimeException : ** event IS NOT a breakpoint ** (P4) JDK-6604963: Assigning float value to int and long throws invalid type exception. (P4) JDK-8167253: com.sun.jdi invokeMethod has duplicated @throws for InvalidTypeException (P4) JDK-4613913: Four EventRequest methods are invokable on deleted request (P4) JDK-8196909: gcc 7.2.1 compiler warning in libdt_socket (P4) JDK-8205508: hotspot/jtreg/vmTestbase/nsk/jdb/exclude/exclude001/exclude001.java fails with Prompt is not received during 300200 milliseconds. (P4) JDK-4462897: JDI spec: ClassType.newInstance() throws IllegalArgumentException (P4) JDK-4447344: JDI spec: several pending JDI step requests are allowed per one thread (P4) JDK-4916621: JDI tests: update those still using JDIScaffold to use TestScaffold instead (P4) JDK-8203329: JDWP/JDI VM information string is incorrect (P4) JDK-8049695: nsk/jdb/options/connect/connect003 fails with "Launched jdb could not attach to debuggee during 300000 milliseconds" (P4) JDK-8198533: Remove obsolete JDIScaffold class from the repo (P4) JDK-8194143: remove unneeded casts in LocationImpl and MirrorImpl classes (P4) JDK-8196992: Resolve disabled warnings for libdt_socket (P4) JDK-8191037: test nsk/jdb/exclude/exclude001 hangs with timeout : exit status: 151 (P4) JDK-8205540: test/hotspot/jtreg/vmTestbase/nsk/jdb/trace/trace001/trace001.java fails with Debuggee did not exit after 15 commands (P4) JDK-8196308: Update tests AllLineLocations and ClassesByName to use TestScaffold instead of JDIScaffold (P4) JDK-8196324: Update tests FilterMatch and FilterNoMatch to use TestScaffold instead of JDIScaffold (P4) JDK-8205719: Windows Java_sun_tools_attach_VirtualMachineImpl_enqueue() method should include exitCode in exception message core-svc/java.lang.instrument: (P3) JDK-8199467: Compilation Errors in libinstrument Reentrancy.c with VS2017 (P4) JDK-8198393: Instrumentation.retransformClasses() throws NullPointerException when handling a zero-length array core-svc/java.lang.management: (P2) JDK-8202564: java/lang/management/ThreadMXBean/ThreadCounts.java fails (P2) JDK-8192953: sun/management/jmxremote/bootstrap/*.sh tests fail with error : revokeall.exe: Permission denied (P3) JDK-8196325: GarbageCollectionNotificationInfo has same information for before and after (P3) JDK-8201327: Make Sensor deeply immutably thread safe (P3) JDK-8199040: Quarantine fromTonga/nsk/monitoring/MemoryPoolMBean/isUsageThresholdExceeded/isexceeded003/TestDescription.java (P3) JDK-8198836: Quarantine MemoryPoolMBean/isUsageThresholdExceeded/isexceeded001/TestDescription.java (P3) JDK-8071367: Remove SNMP agent (P4) JDK-8196028: JMX: Not enough JDP packets received before timeout (P4) JDK-8204173: Lower the minimum number of heap memory pools in MemoryTest.java (P4) JDK-8198253: ThreadInfo.from(CompositeData) incorrectly accepts CompositeData with missing JDK 6 attributes core-svc/javax.management: (P2) JDK-8206211: Drop JVM-MANAGEMENT-MIB.mib from Java SE (P4) JDK-8204661: Show error 'Port already in use' in HashedPasswordFileTest.java core-svc/tools: (P3) JDK-8193710: jcmd -l and jps commands do not list Java processes running in Docker containers (P3) JDK-8197387: jcmd started by "root" must be allowed to access all VM processes (P4) JDK-8202650: Enforce group for attach listener file (P4) JDK-8188856: Incorrect file path in an exception message when .java_pid is not accessible on Unix (P4) JDK-6640188: Methods com.sun.tools.attach.VirtualMachine.load... don't throw NullPointerException (P4) JDK-8199924: Solaris: Correctly enqueue null arguments of attach operations (P4) JDK-8201247: Various cleanups in the attach framework deploy: (P4) JDK-8201210: modified files in JEP-179 need copyright year updated. deploy/packager: (P3) JDK-8183171: Figure out if error needs to be logged (P3) JDK-8195075: Old app window is not reactivatable (P4) JDK-8195074: Improve signing mechanism on Mac 10.12+ deploy/webstart: (P2) JDK-8195609: DRS - cert based run rule not working when running offline docs: (P3) JDK-8066570: Highlight Charset aliases in encoding docs (P3) JDK-8223925: No document covering default property files and system properties of the Preferences API (P4) JDK-8218696: Broken link to AppCDS in JDK 11 documentation (P4) JDK-8218697: Typo in JDK 11 documentation - "the operation system." (P4) JDK-8274089: Update JMX doc content docs/guides: (P2) JDK-8207216: [doc] Add RSASSA-PSS Signature support to SunMSCAPI (P2) JDK-8211391: Java Flight Recorder docs link from JDK 11 docs page is out of date (P3) JDK-8143368: Document JarSigner and X509CertificateBuilder (P3) JDK-8173224: Document jdk.tls.legacyAlgorithms security property (P3) JDK-8208156: Each JCE provider should document the EC curves that they support (P3) JDK-8211323: Link to JDWP spec missing from Specifications section of JDK 11 docs (P3) JDK-8201438: Native GSSAPI Provider not documented in security guides (P3) JDK-8220542: Remove references to policytool from documentation (P3) JDK-8076035: Security Guide Updates for LoginModule loading change (JDK-8047789) (P3) JDK-8201319: Typo in JDK Providers doc: PBEWithSHA1AndPC4_128 (P3) JDK-8202444: Typos in JDK 10 JDK Providers doc (P3) JDK-8058585: Update security guides with information about using module URLs in policy files (P3) JDK-8199358: Update the monitoring and management user guide to remove SNMP monitoring (P4) JDK-8177291: [doc] weak algorithms and crypto policy in JGSS docs (P4) JDK-8200401: Add a note in Sasl Programming guide on weak mechanisms (P4) JDK-8196600: Add example to show how to have TrustManager take the validity dates of trust anchors into account (P4) JDK-8049711: document com.sun.security.jgss.inquiretype. for GSSAPI mechanism (P4) JDK-8073643: Document the system property jdk.tls.rejectClientInitiatedRenegotiation (P4) JDK-8200309: Document XML Signature secure mode (P4) JDK-8180135: Document: Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for JSSE (P4) JDK-8173750: Some syntax errors and bugs in Jarsigner documentation (P4) JDK-8059773: Update PKCS#11 Reference Guide to add support for Mac OSX (P4) JDK-8193855: Update The Kerberos 5 GSS-API Mechanism page with new etypes docs/hotspot: (P3) JDK-8200476: Update java tool reference guide to remove CheckEndorsedAndExtDirs option docs/tools: (P2) JDK-8202223: Document UseAppCDS change in JDK 11 (P2) JDK-8193906: JDK Documentation needs to be updated to remove the Java EE related tools (P2) JDK-8196510: JDK man pages need to be updated to remove the Java EE related tools and the rmic -iiop and -idl options (P3) JDK-8149603: -extdirs option issue (P3) JDK-8204141: [doc] Fix documentation about the -Xshare:on option (P3) JDK-8200348: Clarify documentation of the HotSpot -XX:SharedArchiveConfigFile option (P3) JDK-8150226: doc change for JDK-8130302 (P3) JDK-8197784: doc change for JDK-8191438 on jarsigner (P3) JDK-8217478: Doc changes in Jhsdb page (P3) JDK-8217481: Doc changes in Jinfo page (P3) JDK-8217483: Doc changes in Jstack page (P3) JDK-8217482: Doc changes Jmap in page (P3) JDK-8196447: docs need to describe special considerations for using the Attach API with docker part #2 (P3) JDK-8200467: Document various tools' new --enable-preview option (P3) JDK-8211357: javadoc reference page documents wrong default for -frames (P3) JDK-8211356: javadoc reference page documents wrong default for -html5 (P3) JDK-8205693: jlink tool guide: update jlink --module-path to drop $JAVA_HOME/jmods from examples (P3) JDK-8202729: jlink tool reference: remove listing of unsupported jlink plugins (P3) JDK-8201653: The tools reference page must be updated to reflect --enable-preview (P4) JDK-8199213: Add documentation for JDK-8198691 to Tools Reference Guide (P4) JDK-8192844: DOC: jshell Tool Reference -- option -? added (P4) JDK-8214493: Update JDK Tools Ref with changes in eng markdown globalization/translation: (P3) JDK-8207948: JDK 11 L10n resource file update - msg drop 10 (P3) JDK-8208663: JDK 11 L10n resource file update - msg drop 20 hotspot: (P2) JDK-8207392: [PPC64] Implement JFR profiling. (P2) JDK-8202672: Build failed in metaspace.cpp with VS2017 (P3) JDK-8205172: 32 bit build broken (P3) JDK-8205528: Base64 encoding algorithm using AVX512 instructions (P3) JDK-8197412: Enable docker container related tests for linux s390x (P4) JDK-8202435: [aix] print program break as part of memory info into hs-err file (P4) JDK-8194814: [ppc, s390] A row of minor fixes and cleanups (P4) JDK-8202676: AArch64: Missing enter/leave around barrier leads to infinite loop (P4) JDK-8207584: ARM32: ShouldNotReachHere assertion on Test8168712 jtreg test (P4) JDK-8198439: Fix aarch64 code for handling generate_code_for after FastTLABFill obsolete code (P4) JDK-8200384: jcmd help output should be sorted (P4) JDK-8202634: Metaspace: simplify SpaceManager lists (P4) JDK-8202134: Non-PCH build for arm32 fails (P4) JDK-8203305: PPC64: Improve TM detection for enabling RTM on Linux / POWER9 (P4) JDK-8198825: Resolve missing review feedback for JDK-8170976 (P4) JDK-8199667: Unify metaspace list index handling and reinstantiate ChunkManager listindex gtest (P4) JDK-8200197: Zero fails to build after 8200105 (P4) JDK-8203030: Zero s390 31 bit size_t type conflicts in shared code hotspot/compiler: (P1) JDK-8205034: [BACKOUT] Induction variable of over-unrolled loop conflicts with range checks (P1) JDK-8204570: [Graal] java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessByte.java fails with Graal (P1) JDK-8206975: AArch64: Fix CompareAndSwapOp when useLSE is enabled in Graal (P1) JDK-8207838: AArch64: Float registers incorrectly restored in JNI call (P1) JDK-8206163: AArch64: incorrect code generation for StoreCM (P1) JDK-8207046: arm32 vm crash: C1 arm32 platform functions parameters type mismatch (P1) JDK-8204479: Bitwise AND on byte value sometimes produces wrong result (P1) JDK-8200297: Build failures after JDK-8198691 (CodeHeap State Analytics) (P1) JDK-8199603: Build failures after JDK-8199421 "Add support for vector popcount" (P1) JDK-8204157: Compiler.sunflow hangs after JDK-8192992 (P1) JDK-8209670: CompilerThread releasing code buffer in destructor is unsafe (P1) JDK-8209735: Disable avx512 by default (P1) JDK-8199422: Hotspot build is broken after push of 8197235 (P2) JDK-8206088: 8205207 broke builds (P2) JDK-8194984: 9 Null pointer dereference defect groups related to ciMethodData::bci_to_data() (P2) JDK-8204628: [AArch64] Assertion failure in BarrierSetAssembler::load_at (P2) JDK-8204606: [Aarch64] SIGSEGVs caused by C1 because of improper register usage (P2) JDK-8202273: [AOT] Graal does not support the CMS collector (P2) JDK-8207915: [AOT] jaotc w/ '--ignore-errors' should ignore illegal class files (P2) JDK-8201850: [AOT] vm crash when run test compiler/aot/fingerprint/SelfChangedCDS.java (P2) JDK-8198909: [Graal] compiler/codecache/stress/UnexpectedDeoptimizationTest.java crashed with SIGSEGV (P2) JDK-8195979: [Graal] crash in src/hotspot/share/runtime/mutex.cpp:1341 when Graal JIT is used (P2) JDK-8201794: [Graal] fix regressions from JDK-8187490 (P2) JDK-8203186: [Graal] The result of code execution are different for Graal and Interpreter/C2 (P2) JDK-8205033: [REDO] Induction variable of over-unrolled loop conflicts with range checks (P2) JDK-8202425: [s390] C2: Wrong unsigned comparison with 0 (P2) JDK-8193266: AArch64: TestOptionsWithRanges.java SIGSEGV (P2) JDK-8207345: AArch64: Trampoline generation code reads from uninitialized memory (P2) JDK-8201367: assert(current != first_mem) failed: corrupted memory graph in superword code (P2) JDK-8197563: assert(is_Loop()) crash in PhaseIdealLoop::try_move_store_before_loop() (P2) JDK-8203425: assert(is_Loop()) failed: invalid node class (P2) JDK-8205515: assert(opcode == Op_RangeCheck) failed: no other if variant here (P2) JDK-8193130: Bad graph when unrolled loop bounds conflicts with range checks (P2) JDK-8202565: C1 compilation crashes with "assert(is_double_stack() && !is_virtual()) failed: type check" (P2) JDK-8207355: C1 compilation hangs in ComputeLinearScanOrder::compute_dominator (P2) JDK-8203196: C1 emits incorrect code due to integer overflow in _tableswitch keys (P2) JDK-8205499: C1 temporary code buffers are not removed with -XX:+UseDynamicNumberOfCompilerThreads (P2) JDK-8205999: C2 compilation fails with "assert(store->find_edge(load) != -1) failed: missing precedence edge" (P2) JDK-8202123: C2 Crash in Node::in(unsigned int) const+0x14 (P2) JDK-8202950: C2: assert(found_sfpt) failed: no node in loop that's not input to safepoint (P2) JDK-8202948: C2: assert(init_offset >= 0) failed: positive offset from object start (P2) JDK-8202747: C2: assert(mode == ControlAroundStripMined && use == sfpt) failed: missed a node (P2) JDK-8207746: C2: Lucene crashes on AVX512 instruction (P2) JDK-8200288: Compilation fails with "assert(!(is_cti(prev) && is_cti(insn))) failed: CTI-CTI not allowed" on SPARC (P2) JDK-8202179: Compilation fails with assert(n->is_expensive()) failed: expensive nodes with non-null control here only (P2) JDK-8187676: Disable uninitialized warnings for two files until proper fix available (P2) JDK-8203480: IncompatibleClassChangeError thrown at sites linked to default interface methods (P2) JDK-8203915: Induction variable of over-unrolled loop conflicts with range checks (P2) JDK-8202769: jck test fails with C2: vm/jvmti/FollowReferences/fref001/fref00113/fref00113.html (P2) JDK-8198703: Missing #include "gc/shared/cardTableModRefBS.hpp" in graphKit.hpp (P2) JDK-8202949: Over-unrolled loop with negative stride is partially removed (P2) JDK-8200290: Scratch buffer creation fails with "assert(!current_thread_in_native()) failed: must not be in native" on SPARC (P2) JDK-8200282: Serializing non-zero byte as zero to ByteBuffer (P2) JDK-8200366: SIGSEGV in CodeHeapState::print_names() (P2) JDK-8205105: VM crashes with "assert(Universe::heap()->is_in_reserved(start + words - 1)) failed: not in heap" (P3) JDK-8202848: -XX:+ExecuteInternalVMTests asserts with "assert(cd.valid() == true) failed: failed on a valid DirectivesParser string" (P3) JDK-8206873: 2 Null pointer dereference defect groups in LIRGenerator (P3) JDK-8146201: [AOT] Class static initializers that are not pure should not be executed during static compilation (P3) JDK-8207069: [AOT] we should check that VM uses the same GC as one used for AOT library generation. (P3) JDK-8202399: [C1] LIRGenerator::do_CheckCast needs to exclude is_invokespecial_receiver_check() when using PatchAlot (P3) JDK-8204209: [Graal] Compilation fails during nmethod printing with "assert(bci == 0 || 0 <= bci && bci < code_size()) failed: illegal bci" (P3) JDK-8203187: [Graal] Compilation fails with StackOverflowError (P3) JDK-8205400: [Graal] compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java fails with can't be enqueued for compilation on level 4 (P3) JDK-8193241: [Graal] implement missing intrinsics (P3) JDK-8195632: [Graal] Introduce EagerJVMCI flag to force eager JVMCI initialization (P3) JDK-8202305: [Graal] org.graalvm.compiler.core.test.GraphResetDebugTest fails with java.util.ServiceConfigurationError (P3) JDK-8181855: [Graal] runtime/ReservedStack/ReservedStackTest.java triggers: assert(thread->deopt_mark() == __null) failed: no stack overflow from deopt blob/uncommon trap (P3) JDK-8207383: [Graal] SelfChangedCDS.java fails with "guarantee(disp == (intptr_t)(jint)disp) failed: must be 32-bit offset" (P3) JDK-8199066: [JVMCI] EagerJVMCI option should also initialize the JVMCI compiler (P3) JDK-8189101: AARCH32 - 'minimal' build fails because CMS bits are referred unconditionally (P3) JDK-8187472: AARCH64: array_equals intrinsic doesn't use prefetch for large arrays (P3) JDK-8201185: AARCH64: bfm instruction encoding hits assert on zero register (P3) JDK-8207240: AARCH64: C2-only VM does not build (P3) JDK-8195588: AArch64: Codegen fix after JDK-8194256 (P3) JDK-8196402: AARCH64: create intrinsic for Math.log (P3) JDK-8189105: AARCH64: create intrinsic for sin and cos (P3) JDK-8204289: AARCH64: enable math intrinsics usage in interpreter and C1 (P3) JDK-8196868: AARCH64: ld/st instructions hit guarantee assert while using sp (P3) JDK-8204353: AARCH64: optimize FPU load and stores in macroAssembler (P3) JDK-8205475: AARCH64: optimize FPU loads and stores in C1_Runtime1_aarch64.cpp (P3) JDK-8202326: AARCH64: optimize string compare intrinsic (P3) JDK-8189103: AARCH64: optimize String indexOf intrinsic (P3) JDK-8189112: AARCH64: optimize StringUTF16 compress intrinsic (P3) JDK-8204473: AARCH64: register post-index addressing mode is not supported directly (P3) JDK-8194256: AARCH64: SIMD shift instructions are incorrectly encoded (P3) JDK-8189113: AARCH64: StringLatin1 inflate intrinsic doesn't use prefetch instruction (P3) JDK-8201597: AArch64: Update relocs for CompiledDirectStaticCall (P3) JDK-8202395: AARCH64: wrong encoding for SIMD instructions zip, trn, uzp (P3) JDK-8199421: Add support for vector popcount (P3) JDK-8200067: Add support for vpclmulqdq for crc32 (P3) JDK-8205398: AES CBC decryption algorithm using AVX512 instructions (P3) JDK-8201604: ARM64 - Build failure after JDK-8193260 (P3) JDK-8205107: assert(c->Opcode() == Op_SafePoint) failed: broken outer loop (P3) JDK-8206135: Building jvm with AOT but without JVMCI should fail at configure time (P3) JDK-8201447: C1 does backedge profiling incorrectly (P3) JDK-8207252: C1 still does eden allocations when TLAB is enabled (P3) JDK-8202465: C1: Casts should not be eliminated for interface types (P3) JDK-8203197: C2: consider all paths in loop body for loop predication (P3) JDK-8200383: Can't build on SPARC Hotspot with code which use math functions (P3) JDK-8202070: Cleanup code after JDK-8200450, JDK-8200366 (P3) JDK-8207065: Cleanup compiler tests for Client VM (P3) JDK-8206271: CodeHeap State Analytics must digest new method state (P3) JDK-8206953: compiler/profiling/TestTypeProfiling.java fails when JVMCI build disabled (P3) JDK-8205472: Deadlock in Kitchensink when trying to print compile queues causing timeout (P3) JDK-8190972: Ensure that AOT/Graal filters out class files containing CONSTANT_Dynamic ahead of full AOT support (P3) JDK-8200247: Experimental Java-Based JIT Compiler for Windows and Mac (P3) JDK-8187490: HotSpotGraalMBean should be moved to Graal management module (P3) JDK-8201368: IfNode::fold_compares() may lead to incorrect execution (P3) JDK-8193935: Illegal countedLoops transformation (P3) JDK-8193126: Incorrect setting of MetaspaceSize and NewSizeThreadIncrease when using JVMCI compiler (P3) JDK-8200477: Integer dot product no longer autovectorised (P3) JDK-8189104: JEP 315: Improve Aarch64 Intrinsics (P3) JDK-8205940: LoadNode::find_previous_arraycopy fails with "broken allocation" assert (P3) JDK-8196294: LoopStripMiningIterShortLoop is set to zero by default (P3) JDK-8207049: Minor improvements of compiler code. (P3) JDK-8206931: Misleading "COMPILE SKIPPED: invalid non-klass dependency" compile log (P3) JDK-8206394: missing ResourceMark in AOTCompiledMethod::metadata_do, AOTCompiledMethod::clear_inline_caches , CompiledMethod::clear_ic_stubs , CompiledMethod::cleanup_inline_caches_impl (P3) JDK-8200299: Non-PCH build for aarch64 fails (P3) JDK-8194987: Null pointer dereference in escape.cpp related to Node::find_out_with() (P3) JDK-8198252: Null pointer dereference in IfNode::fold_compares_helper (P3) JDK-8197828: Null pointer dereference in MultiNode::proj_out_or_null (P3) JDK-8197931: Null pointer dereference in Unique_Node_List::push of node.hpp:1510 (P3) JDK-8199784: PhaseIdealLoop::place_near_use() might return wrong control with loop strip mining (P3) JDK-8196401: PPC64+s390: get_frame_at_stack_banging_point uses wrong PC (P3) JDK-8205580: PPC64: RTM: Don't retry lock on abort if abort was intentional (P3) JDK-8205581: PPC64: RTM: Fix abort on native calls (P3) JDK-8205582: PPC64: RTM: Fix counter for aborts on nested transactions (P3) JDK-8199283: Remove ValueObj class for allocation subclassing for compiler code (P3) JDK-8197235: src/hotspot/share/jvmci/jvmciCompilerToVM.cpp takes 4 minutes to compile on windows (P3) JDK-8204199: Test fails after 8202670 Graal update (P3) JDK-8192992: Test8007294.java failed: attempted to spill a non-spillable item (P3) JDK-8206903: Unable to build Client VM (P3) JDK-8194819: Update Graal (P3) JDK-8202698: Update Graal for JEP 181 - Nest-based access control (P3) JDK-8201532: Update idom to get correct dom depth calculation (P3) JDK-8194740: UseSubwordForMaxVector causes performance regression (P4) JDK-8198826: -XX:+VerifyStack fails with fatal error: ExceptionMark constructor expects no pending exceptions (P4) JDK-8194990: 3 Null pointer dereference defect groups related to CodeCache::find_blob_unsafe() (P4) JDK-8205025: [AOT] make jdk.aot module upgradeable (P4) JDK-8202552: [AOT][JVMCI] Incorrect usage of INCLUDE_JVMCI and INCLUDE_AOT (P4) JDK-8193244: [Graal] abort if trying to use CMS with Graal (P4) JDK-8199624: [Graal] Blocking jvmci compilations time out (P4) JDK-8199896: [Graal] build Graal on all x86 platforms (P4) JDK-8200230: [Graal] Compilations should not be enqueued before Graal is initialized (P4) JDK-8200196: [Graal] implement Object.notify/notifyAll intrinsics (P4) JDK-8199887: [Graal] org.graalvm.compiler.core.test.InfopointReasonTest fails with assertion (P4) JDK-8203504: [Graal] org.graalvm.compiler.debug.test.DebugContextTest fails with java.util.ServiceConfigurationError (P4) JDK-8198848: [Graal] org.graalvm.compiler.replacements.test.ClassCastBytecodeExceptionTest fails in -Xcomp mode (P4) JDK-8198917: [Graal] org.graalvm.compiler.replacements.test.ReplacementsParseTest fails with -XX:-UseCompressedOops (P4) JDK-8193930: [JVMCI] calling ResolvedTypeType.getClassInitializer on an array type crashes (P4) JDK-8205703: [JVMCI] Expose all GC selection flags (P4) JDK-8194490: [JVMCI] Move `iterateFrames` to C++ (P4) JDK-8198571: [JVMCI] must not install wide vector code unless runtime supports it (P4) JDK-8203370: [JVMCI] UseJVMCICompiler should imply EnableJVMCI (P4) JDK-8204855: [JVMCI][Graal] make JVMCI API changes necessary to support libgraal (P4) JDK-8198894: [PPC64] More generic vector CRC implementation (P4) JDK-8195776: [x86,sparc] A row of minor fixes and enhancements. (P4) JDK-8198293: AARCH64 - Add CPU detection code for Cavium Thunder X2 (P4) JDK-8205694: AArch64: Add test to validate volatile load, store and CAS code generation (P4) JDK-8204341: AArch64: AOT runtime does not need a workaround for far calls (P4) JDK-8205341: AARCH64: Clean up duplicate uzp1 & uzp2 instruction definition (P4) JDK-8200524: AArch64: CPUFeature and Flag enums are not passed through JVMCI (P4) JDK-8202186: AArch64: Debug build VM crashes with PrintC1Statistics option (P4) JDK-8204331: AArch64: fix CAS not embedded in normal graph error. (P4) JDK-8205004: AArch64: fix failures in jtreg ArraysEqCmpTest (P4) JDK-8203041: AArch64: fix overflow in immediate cmp/cmn instruction (P4) JDK-8193193: AArch64: immByteMapBase operand generated for non-CardTable GCs (P4) JDK-8193260: AArch64: JVMCI: Implement trampoline calls (P4) JDK-8196064: AArch64: Merging ld/st into ldp/stp in macro-assembler (P4) JDK-8185505: AArch64: Port AOT (P4) JDK-8204348: AArch64: Remove C2 address reshaping code (P4) JDK-8202710: AARCH64: sporadic jtreg test fail (P4) JDK-8205474: AARCH64: wrong zr encoding for ccmp instruction (P4) JDK-8200251: AArch64::CPUFeature out of sync with VM_Version::Feature_Flag (P4) JDK-8204476: Add additional statistics to CodeCache::print_summary (P4) JDK-8202976: Add C1 lea patching support for x86 (P4) JDK-8164651: adlc fails to compile with Developer Studio 12.5 (P4) JDK-8204087: C++ Interpreter code left over in MethodData (P4) JDK-8200303: C2 should leverage profiling for lookupswitch/tableswitch (P4) JDK-8204237: Clean up incorrectly included .inline.hpp files from jvmciJavaClasses.hpp (P4) JDK-8198691: CodeHeap State Analytics (P4) JDK-8199777: Deprecate -XX:+AggressiveOpts (P4) JDK-8204240: Extend MDO to allow more reasons to be recorded per bci (P4) JDK-8203215: IdealLoopTree::split_outer_loop leaves phi-nodes with only one input (P4) JDK-8194669: jaotc truncates the invalid filename provided to --output (P4) JDK-8198756: Lazy allocation of compiler threads (P4) JDK-8192857: LogCompilation could show the intrinsics more like +PrintIntrinsics (P4) JDK-8197447: LogCompilation throws "couldn't find bytecode" (P4) JDK-8195064: LogCompilation: Chicken and egg startup problem with types (P4) JDK-8197608: MacroAssembler::unimplemented calls global operator new[] (P4) JDK-8203344: Make C1 leal patchable on SPARC (P4) JDK-8202711: Merge tiered compilation policies (P4) JDK-8202377: Modularize C2 GC barriers (P4) JDK-8132287: obsolete the "InlineNotify" flag option (P4) JDK-8203628: Optimize (masked) byte memory comparisons on x86 (P4) JDK-8193927: Optimize scanning code for oops. (P4) JDK-8148871: Possible wrong expression stack depth at deopt point (P4) JDK-8201218: PPC64: Avoid use of yield instruction on spinlock (P4) JDK-8203669: PPC64: Fix jtreg RTM tests after "8203305: Improve TM detection for enabling RTM on Linux / POWER9" (P4) JDK-8194861: PPC64: Need support for VSR spills in ppc.ad (P4) JDK-8199050: reenable concurrent execution of compiler tests (P4) JDK-8195103: Refactor ReduceInitialCardMarks to not assume all GCs use card marks (P4) JDK-8200168: Remove DONT_USE_REGISTER_DEFINES on Sparc (P4) JDK-8071282: remove misc dead code (P4) JDK-8199696: Remove Runtime1::arraycopy (P4) JDK-8200450: Root cause analysis for JDK-8200366 (P4) JDK-8202640: Small C1 cleanups for BarrierSetC1 (P4) JDK-8184349: There should be some verification that EnableJVMCI is disabled if a GC not supporting JVMCI is selected (P4) JDK-8202773: Unhandled oop in JavaThread::collect_counters (P4) JDK-8178825: unused variable threadObj in jvmci_counters_include (P4) JDK-8201193: Use XMM/YMM for objects initialization (P4) JDK-8204614: VM crash when generating ClassCastException in C1 compiled code (P4) JDK-8199220: Zero build broken after 8195103, 8191102 and 8189871 (P5) JDK-8173100: AArch64: -XX:-UseOnStackReplacement does not work together with -XX:+TieredCompilation (P5) JDK-8191954: AArch64: disable UseCISCSpill in C2 hotspot/gc: (P1) JDK-8199685: Access arraycopy build failure with GCC 7.3.1​ (P1) JDK-8195158: Concurrent System.gc() is "upgraded" to stop-the-world System.gc() (P2) JDK-8202367: AIX build broken after JDK-8201543 (P2) JDK-8204094: assert(worker_i < _length) failed: Worker 15 is greater than max: 11 at ReferenceProcessorPhaseTimes (P2) JDK-8196485: FromCardCache default card index can cause crashes (P2) JDK-8202842: G1 footprint regressions in jdk11+10 (P2) JDK-8201826: G1: Don't invoke WeakProcessor if mark stack has overflowed (P2) JDK-8202049: G1: ReferenceProcessor doesn't handle mark stack overflow (P2) JDK-8183910: gc/arguments/TestAggressiveHeap.java fails intermittently (P2) JDK-8205426: Humongous continues remembered set does not match humongous start region one after Remark (P2) JDK-8203319: JDK-8201487 disabled too much queue balancing (P2) JDK-8207044: minimal vm build fail: missing #include (P2) JDK-8203848: Missing remembered set entry in j.l.ref.references after JDK-8203028 (P2) JDK-8198564: Multiple crashes on SPARC (P2) JDK-8205577: parallel/TestPrintGCDetailsVerbose.java fails assertion (P2) JDK-8199406: Performance drop with Java JDK 1.8.0_162-b32 (P2) JDK-8198270: Remove dangerous assert in HandleArea::oops_do() (P2) JDK-8199519: Several GC tests fails with: java.lang.NumberFormatException: Unparseable number: "-" (P2) JDK-8206476: Wrong assert in phase_enum_2_phase_string() in referenceProcessorPhaseTimes.cpp (P2) JDK-8200550: Xcode 9.3 produce warning -Wexpansion-to-defined (P3) JDK-8207007: Add missing license header to zHash.inline.hpp (P3) JDK-8203843: BasicParState::default_estimated_thread_count(false) can return 0 in gtest (P3) JDK-8200232: Build failures after JDK-8200106 (Move NoSafepointVerifier out from gcLocker.hpp) (P3) JDK-8200228: Change default value of HeapSizePerGCThread (P3) JDK-8196071: Change G1 Full GC heap and thread sizing ergonomics (P3) JDK-8207056: Epsilon GC to support object pinning (P3) JDK-8200730: Fix debug=gc+phases time tracking in Remark and Cleanup (P3) JDK-8200169: Flatten G1Allocator class hierarchy (P3) JDK-8196865: G1 log for active workers is wrong (P3) JDK-8137099: G1 needs to "upgrade" GC within the safepoint if it can't allocate during that safepoint to avoid OoME (P3) JDK-8176717: GC log file handle leaked to child processes (P3) JDK-8201370: GC specific data is referred from common precompiled headers and defNewGeneration.cpp (P3) JDK-8199674: Improve G1 Full GC array marking (P3) JDK-8198423: Improve metaspace chunk allocation (P3) JDK-8203262: Incorrect cmpxchg usage in MetaspaceGC::inc_capacity_until_GC (P3) JDK-8201596: java.lang.ref.Reference processing total time logging broken (P3) JDK-8202662: JFR tests fails: Could not find leak with class (P3) JDK-8187577: JVM crash during gc doing concurrent marking (P3) JDK-8202631: JVM_Clone to throw CloneNotSupportException for Reference object (P3) JDK-8199559: objArrayKlass::oop_iterate() and friends must use base_raw() instead of base() (P3) JDK-8201442: objArrayOopDesc::atomic_compare_exchange_oop() must use obj+offset in HeapAccess call (P3) JDK-8198424: Remove G1AllocationContext (P3) JDK-8198430: Remove G1Allocator extension point (P3) JDK-8198431: Remove G1FullCollector extension point (P3) JDK-8198420: Remove unused extension point AllocationContextStats (P3) JDK-8198433: Remove WhiteBox extension point (P3) JDK-8207006: serviceability/sa/TestUniverse.java#id0 crashes with EpsilonGC and AOT (P3) JDK-8202140: TLAB logging is not correct for G1 (P3) JDK-8205020: ZGC: Apply workaround for buggy sem_post() in glibc < 2.21 (P3) JDK-8205050: ZGC: Incorrect use of RootAccess in ZHeapIterator (P3) JDK-8205163: ZGC: Keeps finalizable marked PhantomReference referents strongly alive (P3) JDK-8206316: ZGC: Preferred tmpfs mount point not found on Debian (P3) JDK-8205924: ZGC: Premature OOME due to failure to expand backing file (P3) JDK-8205676: ZGC: Remove TLAB allocations in relocation path (P3) JDK-8205022: ZGC: SoftReferences not always cleared before throwing OOME (P3) JDK-8205024: ZGC: Worker threads boost mode not always enabled when is should be (P4) JDK-8197896: [Backout] JDK-8196602 Change HeapRegionClosure to comply to naming conventions (P4) JDK-8204179: [BACKOUT] OopStorage should use GlobalCounter (P4) JDK-8198546: [Redo] JDK-8196883 G1RemSet::refine_card_concurrently doesn't need to check for cards in collection set (P4) JDK-8153333: [REDO] STW phases at Concurrent GC should count in PerfCounter (P4) JDK-8202079: [s390]: Build failure w/o PCH (P4) JDK-8200627: aarch32 - Broken build after JDK-8198949 (P4) JDK-8204685: Abstraction for TLAB dummy object (P4) JDK-8198445: Access API for primitive/native arraycopy (P4) JDK-8197999: Accessors in typeArrayOopDesc should use new Access API (P4) JDK-8201227: Add ALL_GCS_ONLY (P4) JDK-8202647: Add deduplicate_string function to CollectedHeap (P4) JDK-8202364: Add GCConfig::hs_err_name() to avoid GC-specific code in error reporting (P4) JDK-8202366: Add macro for common loop in GCConfig (P4) JDK-8202989: Add missing decorators in calls to to arraycopy_prologue/epilogue (P4) JDK-8200607: Add missing include dependency in bitMap.hpp (P4) JDK-8202479: Add missing try_resolve_jobject_in_native calls (P4) JDK-8203339: Add oopDesc::field_offset() (P4) JDK-8205922: Add reference iteration mode that skips visiting the referents (P4) JDK-8201800: Add support for adjusting heap addresses in a TLAB (P4) JDK-8202994: Add support for undoing last TLAB allocation (P4) JDK-8202993: Add support for x86 testptr/testq with register and address (P4) JDK-8198268: Add time argument to ConcurrentGCTimer::register_gc_pause_start/_end (P4) JDK-8200429: Adjust object pinning interface on CollectedHeap (P4) JDK-8198269: Allow GCCauseSetter to be used outside of safepoints (P4) JDK-8198267: Allow GCId::current_raw() calls from non-NamedThreads (P4) JDK-8204163: Also detect concurrent GCs in MetaspaceBaseGC.java (P4) JDK-8202705: ARM32 build crashes on long JavaThread offsets (P4) JDK-8202379: ARM32 is broken after JDK-8201543 (Modularize C1 GC barriers) (P4) JDK-8204540: Automatic oop closure devirtualization (P4) JDK-8197932: Better split work in rebuild remembered sets phase (P4) JDK-8199925: Break out GC selection logic from GCArguments to GCConfig (P4) JDK-8151171: Bring g1ConcurrentMark files up to current coding conventions (P4) JDK-8201527: Bump default value of G1RefProcDrainInterval (P4) JDK-8197850: Calculate liveness in regions during marking (P4) JDK-8204939: Change Access nomenclature: root to native (P4) JDK-8196602: Change HeapRegionClosure to comply to naming conventions (P4) JDK-8195000: Clean out left-overs in arguments.hpp (P4) JDK-8201244: Clean out unnecessary includes of heap headers (P4) JDK-8198369: Clean up GCId and GCIdMark (P4) JDK-8199742: Clean up state flags in G1CollectorState (P4) JDK-8201171: Cleanup in g1CollectedHeap, change CamelCase to snake_case (P4) JDK-8200234: Cleanup Remark and Cleanup pause code (P4) JDK-8195148: Collapse G1SATBCardTableModRefBS and G1SATBCardTableLoggingModRefBS into a single G1BarrierSet (P4) JDK-8200729: Conditional compilation of GCs (P4) JDK-8202714: Create a MacroAssembler::access_load/store_at wrapper for AArch64 (P4) JDK-8202713: Create a MacroAssembler::access_load/store_at wrapper for S390 and PPC (P4) JDK-8198286: Direct memory accessors in typeArrayOop.hpp should use Access API (P4) JDK-8201487: Do not rebalance reference processing queues if not doing parallel reference processing (P4) JDK-8199781: Don't use naked == for comparing oops (P4) JDK-8043575: Dynamically parallelize reference processing work (P4) JDK-8200385: Eagerly reclaimed humongous objects leave mark in prev bitmap (P4) JDK-8191471: Elastic TLABs for G1 (P4) JDK-8145362: Eliminate BarrierSet::ModRef case tags (P4) JDK-8198510: Enable UseDynamicNumberOfGCThreads by default (P4) JDK-8193063: Enabling narrowOop values for RawAccess accesses (P4) JDK-8154736: enhancement of cmpxchg and copy_to_survivor for ppc64 (P4) JDK-8198515: Extract SoftReferencePolicy code out of CollectorPolicy (P4) JDK-8205064: Fail immediately if an unavailable GC is selected (P4) JDK-8204165: Filter out tests requiring class unloading when ClassUnloading is disabled (P4) JDK-8204504: Fix for 8198285 breaks slowdebug builds (P4) JDK-8201427: Fix Minimal VM builds on Linux x64 (P4) JDK-8199328: Fix unsafe field accesses in heap dumper (P4) JDK-8129440: G1 crash during concurrent root region scan (P4) JDK-8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results (P4) JDK-6672778: G1 should trim task queues more aggressively during evacuation pauses (P4) JDK-8201491: G1 support for java.lang.ref.Reference precleaning (P4) JDK-7127700: G1: Replace G1PLAB with PLAB (P4) JDK-8200362: G1Mux2Closure should disable implicit oop verification (P4) JDK-8196883: G1RemSet::refine_card_concurrently doesn't need to check for cards in collection set (P4) JDK-8183003: GC Barrier Interface (P4) JDK-8199886: gc/cslocker/TestCSLocker.java crashes (P4) JDK-8200235: Generalize jniFastGetField jobject/jweak resolve (P4) JDK-8204474: Have instanceRefKlass use HeapAccess when loading the referent (P4) JDK-8204169: Humongous continues region remembered set states do not match the one from the corresponding humongous start region (P4) JDK-8202829: Implement CollectedHeap::get_safepoint_workers() for G1 (P4) JDK-8204180: Implementation: JEP 318: Epsilon, A No-Op Garbage Collector (P4) JDK-8204210: Implementation: JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental) (P4) JDK-8201490: Improve concurrent mark keep alive closure performance (P4) JDK-8200371: In g1, rename ConcurrentMarkThread to G1ConcurrentMarkThread (P4) JDK-8205632: Include stack.inline.hpp in markSweep.inline.hpp (P4) JDK-8204168: Increase small heap sizes in tests to accommodate ZGC (P4) JDK-8203220: Introduce ATTRIBUTE_ALIGNED macro (P4) JDK-8202081: Introduce CollectedHeap::is_oop() (P4) JDK-8201318: Introduce GCThreadLocalData to abstract GC-specific data belonging to a thread (P4) JDK-8203227: Introduce os::processor_id() for Linux and Solaris (P4) JDK-8201646: Introduce ReferenceDiscoverer interface (P4) JDK-8174901: JEP 318: Epsilon: A No-Op Garbage Collector (Experimental) (P4) JDK-8197831: JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental) (P4) JDK-8204554: JFR TLAB tracing broken after 8202776 (P4) JDK-8197844: JVMTI GetLoadedClasses should use the Access API (P4) JDK-8200113: Make Access load proxys smarter (P4) JDK-8198271: Make CollectedHeap::create_heap_space_summary() virtual (P4) JDK-8198265: Make CollectorPolicy::satisfy_failed_metadata_allocation() virtual (P4) JDK-8201647: Make initial clearing of CHeapBitMap optional (P4) JDK-8204082: Make names of Young GCs more uniform in logs (P4) JDK-8205043: Make parallel reference processing default for G1 (P4) JDK-8199027: Make protected members private in G1Policy (P4) JDK-8197570: Make rules for choosing collection set candidates more explicit (P4) JDK-8199927: Make WhiteBox more GC agnostic (P4) JDK-8199735: Mark word updates need to use Access API (P4) JDK-8202017: Merge Reference Enqueuing phase with phase 3 of Reference processing (P4) JDK-8189271: Metaspace::_capacity_until_GC should be size_t (P4) JDK-8204081: Mismatch in rebuild policy and collection set chooser causes remembered sets to be kept errorneously (P4) JDK-8205336: Modularize allocations in assembler (P4) JDK-8198949: Modularize arraycopy stub routine GC barriers (P4) JDK-8201543: Modularize C1 GC barriers (P4) JDK-8202776: Modularize GC allocations in runtime (P4) JDK-8198285: More consistent Access API for arraycopy (P4) JDK-8198530: Move _gc_policy_counters from GenCollectorPolicy to GenCollectedHeap (P4) JDK-8198525: Move _size_policy out of GenCollectorPolicy into GenCollectedHeap (P4) JDK-8198511: Move allocation functions from GenCollectorPolicy to GenCollectedHeap (P4) JDK-8202018: Move card table clear before enqueuing pending references (P4) JDK-8200735: Move CMS specific code from binaryTreeDictionary and freeList to CMS files (P4) JDK-8200736: Move CMSGCStats to the cms directory (P4) JDK-8205664: Move detailed metaspace logging from debug to trace (P4) JDK-8201175: Move FilteringClosure::do_oop to genOopClosures.cpp (P4) JDK-8202547: Move G1 runtime calls used by generated code to G1BarrierSetRuntime (P4) JDK-8201316: Move G1-related static members from JavaThread to G1BarrierSet (P4) JDK-8197852: Move G1DefaultPolicy into G1Policy (P4) JDK-8200737: Move GC code out of Arguments::check_vm_args_consistency into GCArguments (P4) JDK-8201168: Move GC command line constraint functions to GC specific files (P4) JDK-8200759: Move GC entries in vmStructs.cpp to GC specific files (P4) JDK-8201136: Move GC flags from globals.hpp to GC specific files (P4) JDK-8198528: Move GenerationSpecs from GenCollectorPolicy to GenCollectedHeap (P4) JDK-8197994: Move JavaThread::initialize_queues() logic to G1SATBCardTableLoggingModRefBS (P4) JDK-8199946: Move load/store and encode/decode out of oopDesc (P4) JDK-8202722: Move marksweep_init into GC code (P4) JDK-8200106: Move NoSafepointVerifier out from gcLocker.hpp (P4) JDK-8194898: Move OopStorage inline definitions to an .inline.hpp (P4) JDK-8199850: Move parsing of VerifyGCType to G1 (P4) JDK-8200292: Move PushAndMarkVerifyClosure::do_oop_work to concurrentMarkSweepGeneration.cpp (P4) JDK-8198509: Move satisfy_failed_metadata_allocation out from CollectorPolicy (P4) JDK-8197992: Move the OopStorage::ParState type out of inline.hpp (P4) JDK-8202649: Move the Parallel GC specific task creation functions out of Threads (P4) JDK-8202813: Move vm_weak processing from SystemDictionary to WeakProcessor (P4) JDK-8197454: Need Access decorator for storing oop into uninitialized location (P4) JDK-8203157: Object equals abstraction for BarrierSetAssembler (P4) JDK-8197928: Only enqueue deferred cards with references into regions that have a tracked remembered set during GC (P4) JDK-8200557: OopStorage parallel iteration scales poorly (P4) JDK-8202945: OopStorage should use GlobalCounter (P4) JDK-8196876: OopStorage::assert_at_safepoint clashes with assert_at_safepoint macros in g1CollectedHeap.hpp (P4) JDK-8204617: ParallelGC parallel reference processing does not set MT degree in reference processor (P4) JDK-8201172: Parallelize Remset Tracking Update Before Rebuild phase (P4) JDK-8204287: Phase timings not updated correctly after JDK-6672778 (P4) JDK-8203172: Primitive heap access for interpreter BarrierSetAssembler/aarch64 (P4) JDK-8200623: Primitive heap access for interpreter BarrierSetAssembler/x86 (P4) JDK-8201492: Properly implement non-contiguous generations for Reference discovery (P4) JDK-8202230: Provide accessors for JNIHandles storage objects (P4) JDK-8180415: Rebuild remembered sets during the concurrent cycle (P4) JDK-8154528: Reclaim regions emptied by marking in Remark pause (P4) JDK-8191567: Refactor ciInstanceKlass G1 keep alive barrier to use Access API. (P4) JDK-8191888: Refactor ClassLoaderData::remove_handle to use the Access API (P4) JDK-8197569: Refactor eager reclaim for concurrent remembered set rebuilding (P4) JDK-8205683: Refactor heap allocation to separate concerns (P4) JDK-8195972: Refactor oops in JNI to use the Access API (P4) JDK-8195142: Refactor out card table from CardTableModRefBS to flatten the BarrierSet hierarchy (P4) JDK-8202845: Refactor reference processing for improved parallelism (P4) JDK-8203641: Refactor String Deduplication into shared (P4) JDK-8204941: Refactor TemplateTable::_new to use MacroAssembler helpers for tlab and eden (P4) JDK-8191904: Refactor weak oops in ResolvedMethodTable to use the Access API (P4) JDK-8191894: Refactor weak references in JvmtiTagHashmap to use the Access API (P4) JDK-8192003: Refactor weak references in StringTable to use the Access API (P4) JDK-8201362: Remove CollectedHeap::barrier_set() (P4) JDK-8198507: Remove CollectorPolicy::create_rem_set (P4) JDK-8198373: Remove CollectorPolicy::is/as functions (P4) JDK-8197573: Remove concurrent cleanup and secondary free list handling (P4) JDK-8200105: Remove cyclic dependency between oop.inline.hpp and collectedHeap.inline.hpp (P4) JDK-8198896: Remove dead code: cardTableModRefBSForCTRS.hpp (P4) JDK-8202780: Remove EnqueueTask related code from ReferenceProcessor after JDK-8202017 (P4) JDK-8202083: Remove explicit CMS checks in CardTableBarrierSet (P4) JDK-8202082: Remove explicit CMS checks in CardTableBarrierSetAssembler (P4) JDK-8202418: Remove explicit CMS checks in CardTableBarrierSetAssembler: ARM32 leftovers (P4) JDK-8199326: Remove G1 gc time stamp logic (P4) JDK-8200255: Remove G1CMTask::_concurrent (P4) JDK-8200074: Remove G1ConcurrentMark::_concurrent_marking_in_progress (P4) JDK-8201365: Remove G1Policy::should_process_references() (P4) JDK-8204585: Remove IN_ARCHIVE_ROOT from Access API (P4) JDK-8205559: Remove IN_CONCURRENT_ROOT Access decorator (P4) JDK-8201213: Remove INCLUDE_ALL_GCS from memset_with_concurrent_readers (P4) JDK-8201212: Remove INCLUDE_ALL_GCS from OopStorage files (P4) JDK-8197993: Remove last use of JavaThread::flush_barrier_queues() (P4) JDK-8201167: Remove MacroAssembler::cmp_heap_oop on x86 (P4) JDK-8199728: Remove oopDesc::is_scavengable (P4) JDK-8144992: Remove OopIterateClosure::idempotent (P4) JDK-8204084: Remove the G1RSBarrierRegionFilter develop flag (P4) JDK-8199024: Remove unneccessary protected and virtual modifiers from G1CollectedHeap (P4) JDK-8197845: Remove unnecessary method G1CollectedHeap::create_g1_policy (P4) JDK-8202592: Remove unused EvacuateFollowersClosure (P4) JDK-8197847: Remove unused file g1ParScanThreadState_ext.cpp (P4) JDK-8198957: Remove unused function ArgumentsExt::set_gc_specific_flags (P4) JDK-8197841: Remove unused function Universe::create_heap_ext (P4) JDK-8197842: Remove unused macros VM_STRUCTS_EXT and VM_TYPES_EXT (P4) JDK-8197843: Remove unused method G1EvacuationRootClosures::create_root_closures_ext (P4) JDK-8198948: Remove unused parameter evacuation_info from G1CollectedHeap::evacuate_collection_set (P4) JDK-8205679: Remove unused ThreadLocalAllocBuffer::undo_allocate() (P4) JDK-8202591: Remove usage of CMSEdenChunksRecordAlways in defNewGeneration.cpp (P4) JDK-8205459: Rename Access API flag decorators (P4) JDK-8199604: Rename CardTableModRefBS to CardTableBarrierSet (P4) JDK-8202863: Rename OopStorage inner collection classes (P4) JDK-8202641: Replace OOP_SINCE_SAVE_MARKS with templates (P4) JDK-8202642: Replace PAR_OOP_ITERATE with templates (P4) JDK-8200626: Restore history for g1ConcurrentMarkThread.* (P4) JDK-8201209: Separate out CMS specific functions into CMSCardTable (P4) JDK-8199780: SetMemory0 and CopyMemory0 in unsafe.cpp need to resolve their operands (P4) JDK-8199918: Shorten names of CollectedHeap::Name members (P4) JDK-8204097: Simplify OopStorage::AllocateList block entry access (P4) JDK-8203028: Simplify reference processing in light of JDK-8175797 (P4) JDK-8204538: Split ScanClosure and ScanClosureWithParBarrier (P4) JDK-8201217: Split specialized_oop_closures.hpp into GC specific files (P4) JDK-8194804: sun_misc_Cleaner_signature unused (P4) JDK-8199620: Support for JNI object pinning (P4) JDK-8194312: Support parallel and concurrent JNI global handle processing (P4) JDK-8200723: Suppress rs_length and predicted_cards sampling during mixed gcs (P4) JDK-8178105: Switch mark bitmaps during Remark (P4) JDK-8204162: TestG1HeapRegion needs @requires vm.gc.G1 (P4) JDK-8204618: The parallel GC reference processing task executor enqueues a wrong number of tasks into the queue (P4) JDK-8205344: TraceMemoryManagerStats changes in JDK-8195115 broke ZGC (P4) JDK-8204524: Unnecessary memory barriers in G1ParScanThreadState::copy_to_survivor_space (P4) JDK-8199716: Unused AdjustKlassClosure in psParallelCompact.hpp (P4) JDK-8200305: Update gc,liveness output with remset state after rebuild remset concurrently changes (P4) JDK-8202639: Use concrete Generation classes in SerialHeap and CMSHeap (P4) JDK-8199739: Use HeapAccess when loading oops from static fields in javaClasses.cpp (P4) JDK-8202016: Use obj+offset in interpreter array access (P4) JDK-8205607: Use oop_iterate instead of oop_iterate_no_header (P4) JDK-8205405: ZGC: Decouple JFR type registration (P4) JDK-8205993: ZGC: Fix typos and incorrect indentations (P4) JDK-8205338: ZGC: LeakProfiler not yet supported (P4) JDK-8205663: ZGC: Log metaspace used/capacity/committed/reserved (P4) JDK-8205028: ZGC: Remove incorrect comment in ZHeap::object_iterate() (P4) JDK-8205678: ZGC: Remove unused ZAllocationFlags::java_thread() (P4) JDK-8205923: ZGC: Verification applies load barriers before verification (P4) JDK-8205339: ZGC: VerifyBeforeIteration not yet supported (P5) JDK-8202781: Fix typo in DiscoveredListIterator::complete_enqeue (P5) JDK-8203787: Hotspot build broken on linux-sparc after 8202377 (P5) JDK-8202021: Improve variable naming in ReferenceProcessor (P5) JDK-8200426: Make G1 code use _g1h members (P5) JDK-8199516: Remove dead code overlooked during Full GC work (P5) JDK-8133805: Remove the bot_updates parameter from G1Allocator's allocation methods (P5) JDK-8200233: Simple G1 evacuation path performance enhancements (P5) JDK-8201640: Use _ref_processor_* member variables directly in G1CollectedHeap hotspot/jfr: (P1) JDK-8200246: AIX build fails after adjustments of src/hotspot/share/trace/traceEventClasses.xsl (P1) JDK-8205996: JDK-8205906 broke the build on Mac (P1) JDK-8208676: Missing NULL check and resource leak in NetworkPerformanceInterface::NetworkPerformance::network_utilization (P1) JDK-8203288: PPC64 and s390 fail to build after JDK-8199712 (Flight Recorder) (P2) JDK-8203457: Add back missing full buffer notification (P2) JDK-8206006: Build failed on Windows (P2) JDK-8203943: eventThreadGroup was null in TestJavaBlockedEvent.java (P2) JDK-8199712: Flight Recorder (P2) JDK-8193393: JEP 328: Flight Recorder (P2) JDK-8203921: JFR thread sampling is missing fixes from JDK-8194552 (P3) JDK-8198337: -XX:StartFlightRecording=dumponexit=true,disk=false doesn't work (P3) JDK-8207830: [aix] disable jfr in build and tests (P3) JDK-8204571: Add support for launching multiple startup recordings (P3) JDK-8205053: Decouple type registration from framework lifecycle (P3) JDK-8205906: jdk.jfr.jcmd.TestJcmdDumpLimited fails due to erronous processing of -XX:FlightRecorderOptions (P3) JDK-8203237: JFR TestBiasedLockRevocationEvents should ignore events unrelated to the test (P3) JDK-8203346: JFR: Inconsistent signature of jfr_add_string_constant (P3) JDK-8206408: PPC64: add missing info to vm_version_ext_ppc (P3) JDK-8206919: s390: add missing info to vm_version_ext_s390 (P3) JDK-8203299: StringPoolBuffer access covered by exclusive access invariant, remove (problematic) cas operations (P3) JDK-8206254: Unable to complete emergency dump during safepoint (P4) JDK-8203274: 32-bit build failures after JDK-8199712 (Flight Recorder) (P4) JDK-8206004: [BACKOUT] errant changeset for JDK-8137164 (P4) JDK-8203278: AArch64/PPC64 build failures after JDK-8199712 (Flight Recorder) (P4) JDK-8196337: Add commit methods that take all event properties as argument (P4) JDK-8137164: Include PID in the JFR jcmd hint (P4) JDK-8202094: jdk/jfr/api/recording/event/TestEventTime.java intermittently times out (P4) JDK-8027760: JFC schema condition should not have defaults (P4) JDK-8003209: JFR events for network utilization (P4) JDK-8203635: JFR sampler thread does not record stack info (P4) JDK-8204236: JFR unit test of thread CPU load should be enabled (P4) JDK-8203929: Limit amount of data for JFR.dump (P4) JDK-8193400: Milestone 4: Review (P4) JDK-8193402: Milestone 5: Integration (P4) JDK-8203285: Minimal VM fails to build after JDK-8199712 (Flight Recorder) (P4) JDK-8203251: Non-PCH build failed after JDK-8199712 (Flight Recorder) (P4) JDK-8203919: Remove "-add-modules" hint from error message (P4) JDK-8195819: Remove recording=x from jcmd JFR.check output (P4) JDK-8041626: Shutdown tracing event hotspot/jvmti: (P2) JDK-8205096: Add missing files for 8203394" (P2) JDK-8193524: Redefining a method that removes use of 1 or more lambda expressions causes the JVM to hang (P2) JDK-8207763: serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatRateTest.java failed with Error. Parse Exception: Can't find source file: HeapMonitorStatIntervalTest.java (P2) JDK-8205725: Update the JVMTI Spec for Heap Sampling (P3) JDK-8187447: 2081 doc issues in jvmti.html (P3) JDK-8205681: [TEST_BUG] vmTestbase/nsk/jvmti/Allocate/alloc001/TestDescription.java fails with exit code 98 (P3) JDK-8203225: Fix of redefining a method that removes 1 or more lambda expressions failed to commit test cases (P3) JDK-8153629: Need to cover JVMTI's GetOwnedMonitorStackDepthInfo function (P3) JDK-8208075: Quarantine vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineWithoutBytecodeCorruption/TestDescription.java (P3) JDK-8203031: segfaults from jvmti_AddToBootstrapClassLoaderSearch (P3) JDK-8200195: serviceability/jvmti/FieldAccessWatch/FieldAccessWatch.java crashes with "assert(thread->thread_state() == _thread_in_native) failed: coming from wrong thread state" (P3) JDK-8205541: serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatArrayCorrectnessTest.java fails with Should not have any events stored yet. (P3) JDK-8205652: serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatRateTest.java fails with Rate average over 10% for rate 8192 -> 69.0, 1280.0 (P3) JDK-8161605: The '!UseSharedSpaces' check is not need in JvmtiManageCapabilities::recompute_always_capabilities (P4) JDK-8199561: a couple of typos in the JVMTI spec (P4) JDK-8196977: add test for JDK-8161605 (P4) JDK-8203948: Expand JVMTI callback notion of "internal threads" (P4) JDK-8205570: fix a number of typos in the JVMTI spec (P4) JDK-8207765: HeapMonitorStatIntervalTest.java fails with ZGC (P4) JDK-8203394: Implementation of JEP 331: Low-Overhead Heap Profiling (P4) JDK-8171119: JEP 331: Low-Overhead Heap Profiling (P4) JDK-8204961: JVMTI jtreg tests build warnings on 32-bit platforms (P4) JDK-8203802: Jvmti test fails to build with VS2017 (P4) JDK-8187289: NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is disabled (P4) JDK-8193369: post_field_access does not work for some functions, possibly related to fast_getfield (P4) JDK-8208251: serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorGCCMSTest.java fails intermittently on Linux-X64 (P4) JDK-6260469: test nsk/jvmti/GetThreadState/thrstat002 failed (P4) JDK-8205113: Update JVMTI doc references to object allocation tracking hotspot/runtime: (P1) JDK-8198750: [s390+x86_32+aarch64] Fix build after jdk-8195142 (P1) JDK-8209637: [s390x] Interpreter doesn't call result handler after native calls (P1) JDK-8198275: AIX build broken after latest whitebox.cpp changes (P1) JDK-8205091: AIX: build errors in hotspot after 8203641: Refactor String Deduplication into shared (P1) JDK-8198341: Build failures after 8194084 (Obsolete FastTLABRefill and remove the related code) (P1) JDK-8198887: JDK-8168722 broke the build on macosx (P1) JDK-8204292: PPC64: Fix missing includes after 8204195 (P1) JDK-8197572: s390 build broken after 8165929 (P2) JDK-8193429: "assert(false) failed: GetModuleFileName failed (126)" in symbolengine.cpp (P2) JDK-8202381: (Solaris) SIGBUS in # V [libjvm.so+0xcee494] jni_GetIntField+0x224 (P2) JDK-8196372: [BACKOUT] NMT: add_committed_regions doesn't merge succeeding regions (P2) JDK-8196924: [BACKOUT] NMT: Report array class count in NMT summary (P2) JDK-8205609: [PPC64] Fix PPC64 part of 8010319 and TLH without UseSIGTRAP on AIX (P2) JDK-8204335: [ppc] Assembler::add_const_optimized incorrect for some inputs (P2) JDK-8199067: [REDO] NMT: Enhance thread stack tracking (P2) JDK-8195691: AIX build broken after 8194312 (P2) JDK-8205509: assert(_name_and_id != 0LL) failed: encountered a class loader null name and id (P2) JDK-8199219: Build failures after JDK-8195148 (Collapse G1SATBCardTableModRefBS and G1SATBCardTableLoggingModRefBS into a single G1BarrierSet) (P2) JDK-8199619: Building HotSpot on Windows should define NOMINMAX (P2) JDK-8199698: Change 8199275 breaks template instantiation for xlC (and potentially other compliers) (P2) JDK-8202519: Crash during large AppCDS dump (P2) JDK-8189916: Dynamic Constant support for Sparc (P2) JDK-8197906: Enable CDS mode execution of jtreg tests via make (P2) JDK-8203938: Fix build failures from JDK-8133564 (P2) JDK-8199356: Fix hotspot to allow stdlib to use libc++ and to allow changing the deployment target to 10.9 (P2) JDK-8199472: Fix non-PCH build after JDK-8199319 (P2) JDK-8198794: Hotspot crash on Cassandra 3.11.1 startup with libnuma 2.0.3 (P2) JDK-8202669: Intermittent crash in ClassLoadingService::compute_class_size() (P2) JDK-8202080: Introduce ordering semantics for Atomic::add and other RMW atomics (P2) JDK-8207944: java.lang.ClassFormatError: Extra bytes at the end of class file test" possibly violation of JVMS 4.7.1 (P2) JDK-8193897: JDK-8191374 caused windows_i586 build to fail (P2) JDK-8195690: JNI GetObjectRefType doesn't handle NULL (P2) JDK-8204561: JVM_GetClassSigners: wrap signers oop in an objArrayHandle for subsequent safepoint. (P2) JDK-8193213: Make the UseAppCDS option obsolete (P2) JDK-8186046: Minimal ConstantDynamic support (P2) JDK-8205199: more Linux clang compile failures (P2) JDK-8205614: NestMates tests failing in CI jdk11-jdk.931 (P2) JDK-8207139: NMT is not enabled on Windows 2016/10 (P2) JDK-8202289: Non-empty directory in module path is not handled properly at CDS/AppCDS dump time (P2) JDK-8205141: runtime/exceptionMsgs/ArrayStoreException/ArrayStoreExceptionTest.java failed with "assert(k->is_objArray_klass()) failed: cast to ObjArrayKlass" (P2) JDK-8204055: SIGSEGV in java -XX: (P2) JDK-8205965: SIGSEGV on write to NativeCallStack::EMPTY_STACK (P2) JDK-8194759: Support caching class mirror objects (P2) JDK-8206954: Test runtime/Thread/ThreadPriorities.java crashes with SEGV in pthread_getcpuclockid (P2) JDK-8199518: test/hotspot/jtreg/runtime/SelectionResolution tests take a lot longer to run with fastdebug after JDK-8198423 (P2) JDK-8204166: TLH: Semaphore may not be destroy until signal have returned. (P2) JDK-8197589: Update CPU count algorithm when both cpu shares and quotas are used (P2) JDK-8193364: verify_special_jvm_flags should not cause an assertion failure when version is bumped (P2) JDK-8197868: VS2017 (C2065) 'timezone': Undeclared Identifier in share/runtime/os.cpp (P2) JDK-8197864: VS2017 (C4334) Result of 32-bit Shift Implicitly Converted to 64 bits (P2) JDK-8197956: VS2017 (C4838) Narrowing conversion required from __int64 to julong (P2) JDK-8198304: VS2017 (C4838, C4312) Various conversion issues with gtest tests (P2) JDK-8198640: VS2017 (LNK4281) Link Warning Against Missed ASLR Optimization (P2) JDK-8196880: VS2017 Addition of Global Delete Operator with Size Parameter Conflicts with Arena's Chunk Provided One (P2) JDK-8197859: VS2017 Complains about UINTPTR_MAX definition in globalDefinitions_VisCPP.hpp (P2) JDK-8196882: VS2017 Hotspot Defined vsnprintf Function Causes C2084 Already Defined Compilation Error (P2) JDK-8196884: VS2017 Multiple Type Cast Conversion Compilation Errors (P2) JDK-8196997: VS2017 The non-Standard std::tr1 namespace and TR1-only machinery are deprecated and will be removed (P2) JDK-8196889: VS2017 Unable to Instantiate OrderAccess::release_store with an Incomplete Class Within an Inlined Method (P2) JDK-8198312: VS2017: Upgrade HOTSPOT_BUILD_COMPILER in vm_version.cpp (P2) JDK-8189766: whitebox failure with -Xcheck:jni (P2) JDK-8200424: Windows build fails due to implicit jboolean to bool conversion (P3) JDK-8200078: [Graal] runtime/appcds/GraalWithLimitedMetaspace.java crashes in visit_all_interfaces (P3) JDK-8199793: [Graal] runtime/CommandLine/PrintTouchedMethods.java crashes with assertion "reference count underflow for symbol" (P3) JDK-8202150: [REDO] Split globals.hpp to factor out the Flag class (P3) JDK-8206459: [s390] Prevent restoring incorrect bcp and locals in interpreter and avoid incorrect size of partialSubtypeCheckNode in C2 (P3) JDK-8204345: [s390]: no precompiled headers build broken (P3) JDK-8193672: [test] Enhance vm.cds property to check for all conditions required to run CDS tests (P3) JDK-8200628: aarch32 - Broken build after JDK-8199809 (P3) JDK-8206265: aarch64 jtreg: assert in TestOptionsWithRanges.jtr (P3) JDK-8169559: Add class loader names to relevant VM messages (P3) JDK-8167372: Add code to check for getting oops while thread is in native (P3) JDK-8191375: Add high-level jtreg VMProps to filter out CDS tests (P3) JDK-8198908: Add JVM support for preview features (P3) JDK-8204598: add more thread-related system settings info to hs_error file on Linux (P3) JDK-8197972: Always verify non-system classes during CDS dump time (P3) JDK-8199807: AppCDS performs overly restrictive path matching check (P3) JDK-8199557: Assert in fromTonga/vm/runtime/defmeth/scenarios/Stress_noredefine/TestDescription.java (P3) JDK-8205699: assert(_owner_offset != 0) failed in javaClasses.cpp (P3) JDK-8205702: assert(UseCompressedClassPointers) failed in universe.hpp (P3) JDK-8205006: Assertion failure when rehashing stringtable (P3) JDK-8196083: Avoid locking in OopStorage::release (P3) JDK-8198311: Avoid uses of global malloc and free (P3) JDK-8179887: Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated (P3) JDK-8200608: Build failures after JDK-8191101 (Show register content in hs-err file on assert) (P3) JDK-8201799: Build failures after JDK-8195099 (Concurrent safe-memory-reclamation mechanism) (P3) JDK-8195107: CDS broken due to 8194741 (P3) JDK-8203435: Circular nested dynamic constant test needed to confirm JVMS resolution behavior (P3) JDK-8195730: Classes with signer should not be copied to archive spaces (P3) JDK-8204195: Clean up macroAssembler.inline.hpp and other inline.hpp files included in .hpp files (P3) JDK-8203377: Cleanup the usage of os::file_name_strcmp() in SharedPathsMiscInfo::check() (P3) JDK-8199882: compiler/uncommontrap/TestDeoptOOM.java failed w/ fatal error: ExceptionMark constructor expects no pending exceptions (P3) JDK-8204857: ConcurrentHashTable: Fix parallel processing (P3) JDK-8197901: Crash during GC when logging level is debug (P3) JDK-8205583: Crash in ConcurrentHashTable do_bulk_delete_locked_for (P3) JDK-8198796: Create test case for CDS + condy (P3) JDK-8202606: Deprecate AllowNonVirtualCalls option (P3) JDK-8191421: Deprecate PrintSafepointStatistics, PrintSafepointStatisticsTimeout and PrintSafepointStatisticsCount options (P3) JDK-8205175: Deprecate UnlinkSymbolsALot debugging option (P3) JDK-8196806: Deprecate VMThreadHintNoPreempt and CompilerThreadHintNoPreempt (P3) JDK-8196739: Disable obsolete/expired VM flag transitional warnings (P3) JDK-8193308: Disallow installing user signal handlers for SIGBUS on OSX (P3) JDK-8201556: Disallow reading oops in ClassLoaderData if unloading (P3) JDK-8204680: Disassembly does not display code strings in stubs (P3) JDK-8199809: Don't include frame.inline.hpp and other.inline.hpp from .hpp files (P3) JDK-8196590: Enable docker container related tests for linux AARCH64 (P3) JDK-8196062: Enable docker container related tests for linux ppc64le (P3) JDK-8153107: enabling ObjectSynchronizer::quick_enter() on ARM64 causes hangs (P3) JDK-8202427: Enhance os::print_memory_info on Windows (P3) JDK-8207342: error occurred during error reporting (printing register info) (P3) JDK-8202744: Expired flag removal for JDK 11 (P3) JDK-8194812: Extend class-data sharing to support the module path (P3) JDK-8206255: fix compiler/intrinsics/sha/cli/TestUseSHAOptionOnSupportedCPU.java jtreg test on linux s390x (P3) JDK-8205648: fix for 8205195 breaks secondary error handling (P3) JDK-8010319: Implementation of JEP 181: Nest-Based Access Control (P3) JDK-8179249: Improve process output analysis in CDS tests (P3) JDK-8203481: Incorrect constraint for unextended_sp in frame:safe_for_sender (P3) JDK-8190862: Interpreter never refills TLAB (P3) JDK-8191027: JDK-8190862 work for arch x86/x64 (P3) JDK-8046171: JEP 181: Nest-Based Access Control (P3) JDK-8177279: JEP 309: Dynamic Class-File Constants (P3) JDK-8194246: JVM crashes when calling getStackTrace if stack contains a method that is a member of a very large class (P3) JDK-8203301: Linux-sparc fails to build after JDK-8199712 (Flight Recorder) (P3) JDK-8204301: Make OrderAccess functions available to hpp rather than inline.hpp files (P3) JDK-8193332: MetaspaceShared::check_shared_class_loader_type is not used during archive creation (P3) JDK-8206977: Minor improvements of runtime code. (P3) JDK-8201786: Modularize interpreter GC barriers: ARM32 leftovers (P3) JDK-8204620: ModuleEntry::is_non_jdk_module() determination for what is a jdk module is incorrect (P3) JDK-8203817: Monitor::try_lock() should not call check_prelock_state() (P3) JDK-8198926: Move ClassLoaderData::_dependencies to ClassLoaderData::_handles (P3) JDK-8198760: Move global lock SpaceManager::_expand_lock to MutexLocker.cpp (P3) JDK-8201334: Move runtime/NMT/MallocStressTest.java to hotspot_tier3_runtime (P3) JDK-8201265: Native memory leak in ClassLoader::add_to_exploded_build_list (P3) JDK-8186211: Negative tests for CONSTANT_Dynamic (P3) JDK-8199363: Nestmates performance evaluation (P3) JDK-8191369: NMT: Enhance thread stack tracking (P3) JDK-8200423: Non-PCH build for x86_32 fails (P3) JDK-8200438: Non-PCH x86_32 build failure: err_msg is not defined (P3) JDK-8197780: Null pointer dereference in Klass::is_instance_klass of klass.hpp:532 (P3) JDK-8183238: Obsolete CheckEndorsedAndExtDirs and remove checks for lib/endorsed and lib/ext (P3) JDK-8194084: Obsolete FastTLABRefill and remove the related code (P3) JDK-8202331: Obsolete support for commercial features (P3) JDK-8194085: Obsolete the deprecated SafepointSynchronize flags and remove related code (P3) JDK-8193846: Obsolete the VM option UseUTCFileTimestamp (P3) JDK-8205878: pthread_getcpuclockid is expected to return 0 code (P3) JDK-8174790: Race adding (weak) global JNI handles and determining type of handle (P3) JDK-8206471: Race with ConcurrentHashTable deleting items on insert with cleanup thread (P3) JDK-8200261: Regression with JVM anonymous class (P3) JDK-8198447: Remove ClassLoaderExt::check() (P3) JDK-8194086: Remove deprecated experimental flag UseCGroupMemoryLimitForHeap (P3) JDK-8201649: Remove dubious call_jio_print in ostream.cpp (P3) JDK-8201537: Remove is_alive closure from Klass::is_loader_alive() (P3) JDK-8068593: Remove or repurpose unused PerfCounters from objectMonitor (P3) JDK-8198432: Remove Thread extension point (P3) JDK-8197954: Remove unnecessary intermediary APIs from AppCDS implementation (P3) JDK-8200202: Remove unused _boot_modules_array and _platform_modules_array from classLoader.* (P3) JDK-8199282: Remove ValueObj class for allocation subclassing for gc code (P3) JDK-8173070: Remove ValueObj class for allocation subclassing for runtime code (P3) JDK-8202204: Rename hotspot runtime jtreg constantPool ConstantPool directories (P3) JDK-8154587: Resolution fails for default method named 'clone' (P3) JDK-8200466: Revisit the setting of _transitive_interfaces in InstanceKlass (P3) JDK-8199360: Rework the support for the 'ignored' module options in CDS (P3) JDK-8133564: Runtime - 2nd followup to Validate JVM Command-Line Flag Arguments (P3) JDK-8202740: runtime/8176717/TestInheritFD.java fails with java.lang.RuntimeException: could not match: VM RESULT => RETAINS FD (P3) JDK-8196121: runtime/appcds/ClassLoaderTest.java fails silently (P3) JDK-8195065: runtime/appcds/ProhibitedPackage.java intermittent failure (P3) JDK-8174734: Safepoint sync time did not increase (P3) JDK-8206003: SafepointSynchronize with TLH: StoreStore barriers should be moved out of the loop (P3) JDK-8199012: SEGV in jni_DetachCurrentThread during VM shutdown (P3) JDK-8202758: SIGSEGV calling Class.forName(String,Boolean,ClassLoader) with mocked loader (P3) JDK-8178351: Simplify MetaspaceShared::is_in_shared_space and MetaspaceObj::is_shared (P3) JDK-8081519: Split globals.hpp to factor out the Flag class (P3) JDK-8199263: Split interfaceSupport.hpp to not require including .inline.hpp files (P3) JDK-8203837: Split nmethod unloading from inline cache cleaning (P3) JDK-8176808: Split up metaspace.cpp (P3) JDK-8202605: Standardize on ClassLoaderData::loader_name() throughout the VM to obtain a class loader's name (P3) JDK-8199137: StringInternSync test crashes in exit verification (P3) JDK-8204613: StringTable: Calculates wrong number of uncleaned items. (P3) JDK-8194279: support zhaoxin x86 cpu vendor ids CentaurHauls and Shanghai (P3) JDK-8189140: SystemDictionaryShared::initialize() should be renamed to be more meaningful (P3) JDK-8196194: Test plan for JDK-8194759 Support caching class mirror objects (P3) JDK-8198833: TestMemoryAwareness Docker container fails with too small maximum heap (P3) JDK-8199342: The constant pool forgets it has a Dynamic entry if there are overpass methods (P3) JDK-8168722: Unified Logging configuration output needs simplifying (P3) JDK-8200298: Unify all unix versions of libjsig/jsig.c (P3) JDK-8201505: Use WeakHandle for ProtectionDomainCacheTable and ResolvedMethodTable (P3) JDK-8204563: UseAppCDS obsolete message is confusing (P3) JDK-8193514: UseMembar should not be obsoleted yet (P3) JDK-8189922: UseNUMA memory interleaving vs membind (P3) JDK-8191585: VM anonymous classes created during CDS dump time cause crash (P3) JDK-8198313: Wrap holder object for ClassLoaderData in a WeakHandle (P4) JDK-8187066: -Xlog:help "=debug" example is not quite accurate (P4) JDK-8201475: 8199417 breaks AIX and non-pch on s390 (and presumably aarch64) (P4) JDK-8204652: [aix] fix thread stack allocation, too big stack sizes not recognized (P4) JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build (P4) JDK-8204295: [BACKOUT] - JVMFlag::printError missing ATTRIBUTE_PRINTF (P4) JDK-8199133: [BACKOUT] NMT: Enhance thread stack tracking (P4) JDK-8202151: [BACKOUT] Split globals.hpp to factor out the Flag class (P4) JDK-8193434: [GRAAL] Graal classes are not loaded with -Xshare:dump (P4) JDK-8196626: [Graal] runtime/appcds/UseAppCDS.java crashes with "VM thread using lock Heap_lock (not allowed to block on)" (P4) JDK-8196786: [PPC64+s390] ConstantDynamic support (P4) JDK-8196405: [REDO] NMT: add_committed_regions doesn't merge succeeding regions (P4) JDK-8196923: [REDO] NMT: Report array class count in NMT summary (P4) JDK-8197827: [windows] Small cleanups after JDK-8185712 (P4) JDK-8199243: aarch32: ARM 32 build broken after 8165929 (P4) JDK-8200556: AArch64: assertion failure in debug builds (P4) JDK-8203341: Add a safepoint-aware Semaphore (P4) JDK-8203694: Add a safepoint-aware Semaphore - part 2 (P4) JDK-8198554: Add fuzzy matching for log levels and tags when parsing -Xlog (P4) JDK-8203682: Add jcmd "VM.classloaders" command to print out class loader hierarchy, details (P4) JDK-8203188: Add JEP-181 support to the Zero interpreter (P4) JDK-8200374: Add ThreadsSMRSupport::verify_hazard_pointer_scanned() to verify threads_do() (P4) JDK-8200697: Add utility for spin wait with fallback to yield/sleep (P4) JDK-8191924: Adjust DelegatingClassLoader's metadata space sizing algorithm (P4) JDK-8196565: AIX: Clean up os::javaTimeNanos according to AIX/PASE specification (P4) JDK-8196487: AIX: os::get_summary_cpu_info does not need to call into libperfstat (P4) JDK-8201602: ARM32 - Minimal Dynamic Constant support (P4) JDK-8203354: assert in ClassLoader::update_module_path_entry_list() could have incorrect message (P4) JDK-6909265: assert(_OnDeck != Self->_MutexEvent,"invariant") with -XX:+PrintMallocFree (P4) JDK-8199717: Avoid calculating primordial thread stack bounds on VM startup (P4) JDK-8197408: Bad pointer comparison and small cleanup in os_linux.cpp (P4) JDK-8204850: BarrierSet::make_* should be static (P4) JDK-8204160: BiasedLockingTest needs -XX:+UseBiasedLocking (P4) JDK-8199272: Broken assertion in ClassLoaderData::remove_handle (P4) JDK-8193056: build failure with Xcode 9.1 (P4) JDK-8181503: Can't compile hotspot with c++11 (P4) JDK-8190235: Clarify ClassLoaderData::is_*_class_loader_data() method implementations (P4) JDK-8199007: ClassLoaderDataGraph::unload_list_contains() is wrong (P4) JDK-8200276: Cleanup allocation.hpp includes (P4) JDK-8185034: Cleanup and consolidate Metaspace coding (P4) JDK-8193373: Cleanup ElfFile and family (P4) JDK-8198287: Cleanup ElfFile usage in whitebox.cpp (P4) JDK-8204668: Cleanup management of the java.vm.info System property (P4) JDK-8194691: Cleanup unnecessary casts in Atomic/OrderAccess uses (P4) JDK-8058259: compute_offset() is confusing for static fields (P4) JDK-8195099: Concurrent safe-memory-reclamation mechanism (P4) JDK-8203885: ConcurrentLocksDump::dump_at_safepoint() should not allocate array in resource area (P4) JDK-8165929: Constify arguments of Copy methods (P4) JDK-8182847: Copy class should use assert macros (P4) JDK-8204477: Count linkage errors and print in Exceptions::print_exception_counts_on_error (P4) JDK-8199736: Define WIN32_LEAN_AND_MEAN before including windows.h (P4) JDK-8199511: Do not generate g1_{pre|post}_barrier_slow_id without CardTable-enabled barrier set (P4) JDK-8170941: Executing gtest with invalid -Xlog argument crashes gtestLauncher (P4) JDK-8197857: fieldDescriptor prints incorrect 32-bit representation of compressed oops (P4) JDK-8204167: Filter out tests requiring compressed oops when CompressedOops is disabled (P4) JDK-8199275: Fix inclusions of allocation.inline.hpp (P4) JDK-8203400: Fix issue with "8199852: Print more information about class loaders in LinkageErrors." (P4) JDK-8196907: Fix minimal vm (P4) JDK-8202447: Fix unloading_occurred to mean unloading_occurred (P4) JDK-8203353: Fixup inferred decorators in the interpreter (P4) JDK-8140359: get_locked_message_ext() should return Flag::MsgType (P4) JDK-8200630: Globally suppress Visual Studio warning C4351 (P4) JDK-8201616: Hotspot crashes on linux-sparc after 8189941 (P4) JDK-8191374: Improve error message when CDS is not supported on exploded build (P4) JDK-8204943: Improve message of ArrayStoreException. (P4) JDK-8197405: Improve messages of AbstractMethodErrors and IncompatibleClassChangeErrors. (P4) JDK-8201572: Improve Metaspace reporting (P4) JDK-8204268: Improve some IncompatibleClassChangeError messages. (P4) JDK-8152957: Improve specificity of safepoint logging to print safepoint type (P4) JDK-8190346: improve unified JVM logging help message and warnings (P4) JDK-8198608: Improvements to command-line flags printing (P4) JDK-8201242: Include source file/line number when reporting native call stack on supported platforms (P4) JDK-8201359: Incorrect header guards after JDK-8198949 (Modularize arraycopy stub routine GC barriers) (P4) JDK-8191102: Incorrect include file use in classLoader.hpp (P4) JDK-8202978: Incorrect tmp register passed to MacroAssembler::load_mirror() (P4) JDK-8197429: Increased stack guard causes segfaults on x86-32 (P4) JDK-8201480: ISA/CPU feature detection code crashes on linux-sparc (P4) JDK-8203699: java/lang/invoke/SpecialInterfaceCall fails with SIGILL on aarch64 (P4) JDK-8198553: jcmd: separate Metaspace statistics from NMT (P4) JDK-8203455: jcmd: VM.metaspace: print loader name for anonymous CLDs. (P4) JDK-8191986: JDK-8190862 work for arch aarch64 (P4) JDK-8191985: JDK-8190862 work for arch arm32 (P4) JDK-8191987: JDK-8190862 work for arch ppc64 (P4) JDK-8191989: JDK-8190862 work for arch sparc (P4) JDK-8198906: JDK-8196882 breaks VS2013 Win32 builds (P4) JDK-8203664: JFR start failure after AppCDS archive created with JFR StartFlightRecording (P4) JDK-8194762: JTReg failure of "runtime/NMT/PrintNMTStatistics.java" (P4) JDK-8203939: JVMFlag::printError missing ATTRIBUTE_PRINTF (P4) JDK-8202913: loader constraint message for fields specifies incorrect referring class (P4) JDK-8176298: Log tags in -Xlog:help not sorted (P4) JDK-8202303: LogStream should autoflush on destruction (P4) JDK-8195098: Low latency hashtable for read-mostly scenarios (P4) JDK-8195097: Make it possible to process StringTable outside safepoint (P4) JDK-8201785: Make ModRefBarrierSetAssembler abstract on all platforms (P4) JDK-8199656: Make slow metaspace verifications switchable in debug builds (P4) JDK-8200111: MallocArrayAllocator::free should not take a length parameter (P4) JDK-7179701: MaxJavaStackTraceDepth of zero is not handled correctly/consistently in the VM (P4) JDK-8203865: Metaspace cleanup: Remove unused MemRegion in VirtualSpaceNode (P4) JDK-8197772: metaspace uses global operator new/delete for gtest testing (P4) JDK-8199432: metaspace: fix wrong comment and condition in SpaceManager::verify() (P4) JDK-8202074: Metaspace: If humongous chunk is added to SpaceManager, previous current chunk may not get retired correctly. (P4) JDK-8202424: Metaspace: on chunk retirement, use correct lower limit on chunksize when adding blocks to free blocks list. (P4) JDK-8202073: MetaspaceAllocationTest gtest shall lock during space creation (P4) JDK-8190428: Minimal Dynamic Constant support for AArch64 (P4) JDK-8202684: Minimal VM build is broken after JDK-8199067, JDK-8202638 (P4) JDK-8198845: Missing resource mark results disassembling generated code failure in hs error report (P4) JDK-8199417: Modularize interpreter GC barriers (P4) JDK-8198474: Move JNIHandles::resolve into jniHandles.inline.hpp (P4) JDK-8202709: Move oopDesc::is_archive_object to MetaspaceShared::is_archive_object (P4) JDK-8130039: Move the platform-specific [OS]Semaphore code (P4) JDK-8134537: Much nearly duplicated code for sun.misc.Signal support (P4) JDK-8205195: NestedThreadsListHandleInErrorHandlingTest fails because hs_err doesn't contain _nested_thread_list_max (P4) JDK-8202772: NMT thread stack tracking causes crashes on AIX (P4) JDK-8196217: NMT: add_committed_regions doesn't merge succeeding regions (P4) JDK-8204557: NMT: Linux os::committed_in_range() does not break out outer loop when contiguous region is found (P4) JDK-8199752: NMT: Memory allocated by Unsafe.allocateMemory should be tagged as mtOther (P4) JDK-8194934: NMT: Remove MemTracker::get_virtual_memory_xxx_tracker(), create Tracker in place (P4) JDK-8193184: NMT: Report array class count in NMT summary (P4) JDK-8194925: NMT: SummarySanityCheck test can't parse values > max_jint (P4) JDK-8199741: NMT: Tag safepoint polling pages. (P4) JDK-8201321: NMT: Unnecessary re-recording thread stack and size when attaching listener to JavaThread (P4) JDK-8202853: NotifyCount is not initialized (P4) JDK-8184289: Obsolete -XX:+UnsyncloadClass and -XX:+MustCallLoadClassInternal options (P4) JDK-8182731: Odd handling of -XX:-UseAppCDS and -XX:SharedArchiveFile (P4) JDK-8204164: OOM-only logging in Metaspace (P4) JDK-8200555: OopHandle should use Access API (P4) JDK-8198225: os::attempt_reserve_memory_at records memory as committed (P4) JDK-8192927: os::dir_is_empty is incorrect on Windows (P4) JDK-8194763: os::signal_lookup is unused (P4) JDK-8203680: os::stat() on Posix platform does not need to copy input path (P4) JDK-8197789: os::SuspendedThreadTask causes references to global operator delete (P4) JDK-8202014: Possible to receive signal before signal semaphore created (P4) JDK-8200302: ppc, s390 (non-pch) build errors (P4) JDK-8201593: Print array length in ArrayIndexOutOfBoundsException. (P4) JDK-8203292: Print complete set of flags in the hs_err file (P4) JDK-8205925: Print correct and more information about secondary errors. (P4) JDK-8203881: Print erroneous size in NegativeArraySizeException (P4) JDK-8199940: Print more information about class loaders in IllegalAccessErrors (P4) JDK-8199852: Print more information about class loaders in LinkageErrors. (P4) JDK-8203032: PrintMetaspaceDcmd fails: 'Non-Class:' missing from stdout/stderr (P4) JDK-8201450: Provide access to LogHandle tagset (P4) JDK-8204974: Quarantine serviceability/sa/TestInstanceKlassSize* tests for CDS enabled mode (P4) JDK-8191798: redo nested ThreadsListHandle to drop Threads_lock (P4) JDK-8190359: Reduce the number of recorded klass dependencies (P4) JDK-8196783: Refactor LogTagLevelExpression into separate classes (P4) JDK-8194741: Refactor oops in constant pool from CDS to use the Access API (P4) JDK-8194736: Refactor weak oops in ProtectionDomain table to use the Access API (P4) JDK-8199319: Remove handles.inline.hpp include from reflectionUtils.hpp (P4) JDK-8202745: Remove hyphens from "out-of-bounds". (P4) JDK-8198560: Remove implicit casts from oop to JavaThread* and jlong* (P4) JDK-8186903: Remove j-types from Atomic (P4) JDK-8196199: Remove miscellaneous oop comparison operators (P4) JDK-8202615: Remove NativeMonitorSpinLimit, NativeMonitorFlags and NativeMonitorTimeout experimental flags (P4) JDK-8195857: Remove os::is_headless_jre (P4) JDK-8194994: Remove redundant string streams used for logging (P4) JDK-8202164: Remove some unneeded BoolObjectClosure* is_alive parameters (P4) JDK-8199264: Remove universe.inline.hpp to simplify include dependencies (P4) JDK-8159850: Remove unneeded parsing of optional-size when parsing array types (P4) JDK-8198635: Remove unused safepoint message functions and ShowSafepointMsgs (P4) JDK-8199430: Rename MetaspaceAux to something more meaningful (P4) JDK-8203381: Replace InstanceKlass::allocate_instance_handle with JavaCalls::construct_new_instance (P4) JDK-8199880: runtime/appcds/condy/CondyHelloTest.java missing at requires vm.cds (P4) JDK-8203250: runtime/LoadClass/test-classes/Hello.java has wrong legal notice (P4) JDK-8191101: Show register content in hs-err file on assert (P4) JDK-8199431: Split up Metaspace class into a static and a non-static part (P4) JDK-8203490: StringTable::dump lacks a load barrier (P4) JDK-8193509: Test dynamic path to retrieve active processor count. (P4) JDK-8153945: Track if log configuration has changed during runtime (P4) JDK-8130038: Unify the semaphore usage in os_xxx.cpp (P4) JDK-8194406: Use Atomic::replace_if_null (P4) JDK-8203219: VM.metaspace jcmd should optionally show loaded classes for loaders (P4) JDK-8203343: VM.{metaspace|classloaders|classhierarchy...} jcmd should show invocation targets for Generated{Method|Constructor}AccessorImpl classes (P4) JDK-8194652: VMError::print_native_stack() is missing an os::is_first_C_frame() check (P4) JDK-8175249: VMThread::run fails in VerifyBeforeExit : Universe::verify (P4) JDK-8198558: Windows does not build without precompiled headers (P4) JDK-8195112: x86 (32 bit): implementation for Thread-local handshakes (P4) JDK-8203287: Zero fails to build after JDK-8199712 (Flight Recorder) (P4) JDK-8200245: Zero fails to build on linux-ia64 due to ia64-specific cruft (P4) JDK-8192123: Zero should use compiler built-ins for atomics on linux-arm (P4) JDK-8201509: Zero: S390 31bit atomic_copy64 inline assembler is wrong (P5) JDK-8197455: There is some runthese related unused code in bytecodeInterpreter.cpp hotspot/svc: (P2) JDK-8203321: assert(current_query_index < process_query_set->size) failed: invariant (P3) JDK-8180709: java -javaagent:agent.jar with run-time that does not contain java.instrument prints confusing error (P3) JDK-8206173: MallocSiteTable::initialize() doesn't take function descriptors into account (P3) JDK-8166642: serviceability/dcmd/framework/* timeout (P3) JDK-8202466: Test serviceability/tmtools/jstat/GcTest01.java fails: Number of concurrent GC events is 1, but CGCT is 0 (P4) JDK-8199708: [BACKOUT] serviceability/dcmd/framework/* timeout (P4) JDK-8206960: [Graal] serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitor tests fail (P4) JDK-8198585: add asserts to verify that ServiceUtil::visible_oop is not needed (P4) JDK-8199010: attachListener.hpp: Fix potential null termination issue found by coverity scans (P4) JDK-8203014: jcmd should output command list if no command is given (P4) JDK-8205531: jcmd VM.classloaders should fold similar loaders (P4) JDK-8204958: Minor cleanups for the diagnostic framework (P4) JDK-8200720: Print additional information in thread dump (times, allocated bytes etc.) (P4) JDK-8202889: Remove trailing LF from perf log (P4) JDK-8201542: Remove unused _gc_timer field in GCMemoryManager (P4) JDK-8195109: ServiceUtil::visible_oop is not needed anymore (P4) JDK-8198655: test/lib/jdk/test/lib/apps/LingeredApp shouldn't inherit cout/cerr (P4) JDK-8203391: Update com/sun/jdi/JdbMethodExitTest.sh to pass valid URL[] (P4) JDK-8198933: Update JDI tests to pass valid URL[] hotspot/svc-agent: (P2) JDK-8203689: Add failure code to threaddb exception messages (P3) JDK-8198726: Quarantine SADebugDTest.java again (P3) JDK-8175384: SA: clhsdb 'printall' throws ClassCastException while printing out the bytecodes (P3) JDK-8174995: SA: clhsdb 'where -a' throws Assertion Failure with illegal code 236 when CDS is used (P3) JDK-8174994: SA: clhsdb printmdo throws WrongTypeException when attached to a process with CDS (P3) JDK-8175312: SA: clhsdb: Provide an improved heap summary for 'universe' for G1GC (P3) JDK-8189429: SA: MacOSX: Replace the deprecated PT_ATTACH with PT_ATTACHEXC (P3) JDK-8193352: SA: Test for the clhsdb 'thread' and 'threads' commands (P3) JDK-8204110: serviceability/sa/ClhsdbSymbol.java and ClhsdbInspect.java failed when running in CDS mode (P4) JDK-8195613: [SA] HotSpotTypeDataBase.readVMLongConstants truncates values to int (P4) JDK-8199323: hsdis could not be loaded which are located on long path (P4) JDK-8204531: Remove unused chars following '\0' (P4) JDK-8194249: SA: G1HeapRegionTable#getByAddress() returns incorrect HeapRegion (P4) JDK-8202200: set INCLUDE_SA to false on s390x by default hotspot/test: (P2) JDK-8202000: AIX build broken after JDK-8195099 (P2) JDK-8202748: jtreg :hotspot_misc group shouldn't include vmTestbase tests (P2) JDK-8202559: Tests which start VM using JNI start failing after compile upgrade to VC 2017 (P3) JDK-8194636: Apply CONCURRENCY_FACTOR to max value in concurrency calculation (P3) JDK-8198551: Rename hotspot_tier1 test group to tier1 (P4) JDK-8203437: 8199370 broke build on linux-ppc64le (w/ GCC 4.8.5.) (P4) JDK-8206429: [REDO] 8202561 clean up TEST.groups (P4) JDK-8207067: [test] prevent timeouts in serviceability/tmtools/jstat/{GcTest02,GcCauseTest02}.java (P4) JDK-8206998: [test] runtime/ElfDecoder/TestElfDirectRead.java requires longer timeout on ppc64 (P4) JDK-8203923: Add @requires feature to check flag values for the running JVM (P4) JDK-8186635: ClassFileInstaller should be run as a driver (P4) JDK-8202561: clean up TEST.groups file (P4) JDK-8200187: Exclude 3 long-running tests from tier1 (P4) JDK-8206117: failed to get JDK properties for JVM w/o JVMCI (P4) JDK-8206287: fix legal notice in hotspot tests (P4) JDK-8195002: Fix test/hotspot/jtreg/gtest/GTestWrapper.java on Alpine/Musl (P4) JDK-8197815: Remove empty sanity tests for minimal and client JVM configurations (P4) JDK-8199064: Test applications/jcstress/other/Test.java#id1108 fails on Sparc infrastructure: (P2) JDK-8193660: Check SOURCE line in "release" file for closedjdk (P2) JDK-8196998: Create devkit for Linux with gcc 7.3 (P4) JDK-8199152: Configure broken for arm 32 (P4) JDK-8203479: JFR enabled ARM32 build assertion failure infrastructure/build: (P1) JDK-8209806: API docs should be updated to refer to javase11 (P1) JDK-8196356: Changes to m4 files don't trigger autoconf execution at build time (P1) JDK-8199052: Configure broken on aarch64 (P1) JDK-8196879: Forgot to add file in JDK-8196803 (P1) JDK-8196951: jdk build fails with clang: error: no such file or directory: '@LIBZ_CFLAGS@' (P1) JDK-8201222: JDK-8199539 broke the OpenJDK build (P1) JDK-8201221: JDK-8199608 introduced a build race on macosx (P1) JDK-8202919: JDK-8202683 broke macosx build (P1) JDK-8198303: jdk11+1 was build with incorrect GA date as 2018-03-20 (P1) JDK-8198301: jdk11+1 was built as 'fcs' instead of 'ea' (P1) JDK-8201508: Macosx builds fail in GenerateLinkOptData.gmk (P1) JDK-8196911: Windows build fails with not finding zlib.h (P2) JDK-8197865: @moduleGraph taglet generates incorrect link to module graph (P2) JDK-8204684: [AIX] Build of libjli_static broken after change 8204572 (SetupJdkLibrary) (P2) JDK-8204973: Add build support for filtering translations (P2) JDK-8196524: Align MaxRAMPercentage settings between open and closed (P2) JDK-8201357: ALSA_CFLAGS is needed; was dropped in JDK-8071469 (P2) JDK-8200083: Bump bootjdk used for JDK 11 at Oracle to JDK 10 (P2) JDK-8203795: Change default compiler on Windows to VS2017 (P2) JDK-8196724: Change macosx deployment target to 10.9 (P2) JDK-8200375: Change to GCC 7.3.0 for building Linux at Oracle (P2) JDK-8205424: Change to Xcode 9.4 for building on Macosx at Oracle (P2) JDK-8198328: Create devkit for Solaris with developer studio 12.6 and Solaris11.3 (P2) JDK-8196985: Disable new warnings from GCC 7.3 in jdk libraries (P2) JDK-8201267: Disable warnings for VS2017 to enable building (P2) JDK-8206184: docs-reference build fails due to extlink.spec.version property not set (P2) JDK-8205055: Fix compilation optimization errors with new Solaris toolchain (P2) JDK-8199782: Fix compilation warnings detected by Solaris Developer Studio 12.6 (P2) JDK-8202319: Fix compilation warnings in Solaris debug builds for DevStudio 12.6 (P2) JDK-8207243: Fix translation filtering to also support zh_HK and zh_TW (P2) JDK-8199339: JDK-8198859 broke solaris x64 (P2) JDK-8199745: JDK-8199668 introduced a build race on macosx (P2) JDK-8199884: JDK-8199749 broke build with make 3.81 (P2) JDK-8204109: JDK-8203945 broke nashorn (P2) JDK-8202920: jvm.cfg generation incorrect (P2) JDK-8207365: Make man pages optional (P2) JDK-8206323: Missing some legal notices in docs bundle (P2) JDK-8205197: Never default to using libc++ on Linux (P2) JDK-8202557: OpenJDK fails to start in Windows 7 and 8.1 after upgrading compiler to VC 2017 (P2) JDK-8203667: Platform specific include files in jdk image in wrong sub directory (P2) JDK-8195689: Remove generated-configure.sh and instead use autoconf (P2) JDK-8205627: Replace hardcoded spec version value in build.tools.ExtLink taglet (P2) JDK-8200586: Update JDK 11 release date to 2018-09-25 (P2) JDK-8203932: Windows devkit has wrong dlls in 32 bit tools dir (P3) JDK-8207001: *.obj.log files get truncated causing unreliable incremental builds on Windows (P3) JDK-8198243: Add build time check for global operator new/delete in object files (P3) JDK-8204602: Add devkit for linux-arm32 (P3) JDK-8203822: AIX version of jsig.c was not removed in JDK-8200298 (P3) JDK-8199347: Always use -Z7 for debug symbols when compiling on Windows (P3) JDK-8202974: Backout JDK-8202683 (P3) JDK-8205942: Build failure on macosx after JDK-8189429 (P3) JDK-8001934: build-infra: Unify all RC_FLAGS in CompileNativeLibraries.gmk (P3) JDK-8199405: Bump lowest supported gcc to 4.8 (P3) JDK-8204127: Change bundle format on Windows to zip (P3) JDK-8197571: Change storage location for generated-configure.sh (P3) JDK-8199682: Clean up building the saproc library (P3) JDK-8198844: Clean up GensrcX11Wrappers (P3) JDK-8199608: Clean up LDFLAGS for libfontmanager (P3) JDK-8199483: Clean up some non-standard LDFLAGS usage (P3) JDK-8200174: compare.sh improvements (P3) JDK-8200213: Configure broken on MIPS (P3) JDK-8204922: Create bootcycle jib profiles (P3) JDK-8196895: Create devkit for Macosx with Xcode 9.2 (P3) JDK-8199451: Create linux-aarch64 cross-compilation devkit, and fix cross-compilation (P3) JDK-8199749: Debug symbols are not copied to exploded image on Mac (P3) JDK-8204934: Digital signatures of executables and shared libraries missing for OpenJDK builds (P3) JDK-8202052: Disable warnings when building libawt with VS2017 (P3) JDK-8199331: Don't limit debug information for fastdebug JDK native libraries (P3) JDK-8196197: Enable the make system to calculate concurrency for JDK tests (P3) JDK-8204965: Fix '--disable-cds' and disable CDS on AIX by default (P3) JDK-8196803: Fix build warnings in jdk libraries with Xcode 9 (P3) JDK-8198227: Fix COMPARE_BUILD after forest consolidation (P3) JDK-8200658: Fix incremental builds of hotspot on solaris (P3) JDK-8205956: Fix usage of “OpenJDK” in build and test instructions (P3) JDK-8200357: Inline SoundLibraries.gmk into Lib-java.desktop.gmk (P3) JDK-8199639: Introduce SetupJdkLibrary and SetupJdkExecutable (P3) JDK-8200198: javah man pages were not removed by JDK-8191054 (P3) JDK-8201591: JVM features with "-" in name is not correctly handled (P3) JDK-8198318: Make build comparisons clean again (P3) JDK-8205649: Make clang stack flags independent of OS (P3) JDK-8201483: Make it possible to disable JVM features (P3) JDK-8198450: Make jdk.internal.vm.compiler/module-info.java.extra reproducable (P3) JDK-8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers) (P3) JDK-8207047: Multiple VM variants build fail. (P3) JDK-8204682: Parsing for LOG=report=none is broken when combined with other keywords (P3) JDK-8199224: Refactor add_native_source in SetupNativeCompilation (P3) JDK-8198724: Refactor FLAGS handling in configure (P3) JDK-8198751: Refactor SetupNativeCompilation to take NAME and TYPE (P3) JDK-8199681: Remove boilerplate code from creating native jtreg tests (P3) JDK-8200132: Remove jre images and bundles (P3) JDK-8200358: Remove mapfiles for JDK executables (P3) JDK-8200178: Remove mapfiles for JDK native libraries (P3) JDK-8200867: Remove references to "jdk 9" in build system (P3) JDK-8199403: Require binutils 2.18 or newer (P3) JDK-8200624: Run-test documentation on openjdk.java.net web page is outdated (P3) JDK-8199606: Set -lc as global LIBS on solstudio (P3) JDK-8204572: SetupJdkLibrary should setup SRC and -I flags automatically (P3) JDK-8206433: Several jib profiles missing autoconf dependency (P3) JDK-8200229: Simplify building of libjsig (P3) JDK-8199640: Split up BUILD_LIBKRB5 into the two, unrelated compilations it consists of (P3) JDK-8198862: Stop doing funky compilation stuff for dtrace (P3) JDK-8198652: Stop linking with -base:0x8000000 on Windows (P3) JDK-8201236: Straighten out dtrace build logic (P3) JDK-8200115: System property java.vm.vendor value includes quotation marks (P3) JDK-8203366: tag added wrongly in Docs.gmk (P3) JDK-8199636: Unify naming for jaas_unix and jaas_nt (P3) JDK-8208096: Update build documentation to reflect compiler upgrades at Oracle (P3) JDK-8200469: Update link to license in Docs.gmk (P3) JDK-8173401: Update VERSION_FEATURE for JDK 11 (P3) JDK-8199338: Use -g0 on solstudio also for compiling C programs (P3) JDK-8198859: Use elfedit to silence linker warnings on solaris (P3) JDK-8202738: vm_version Abstract_VM_Version::internal_vm_info_string() returns same string for different incremental builds (P3) JDK-8205183: Warning about using VS2017 should be removed (P3) JDK-8199626: Workaround concurrency/memory issue in langtools makefile (P4) JDK-8199125: --disable-warnings-as-errors does not work for native jtreg test code (P4) JDK-8202325: [aix] disable warnings-as-errors by default (P4) JDK-8204935: [aix] TOC overflow in libjvm.so (release build) (P4) JDK-8043348: [macosx] Run Xcode command line tools from correct path when configured with --with-tools-dir (P4) JDK-8205407: [windows, vs<2017] C4800 after 8203197 (P4) JDK-8201495: [Zero] Reduce limits of max heap size for boot JDK on s390 (P4) JDK-8200267: a.out created at top dir by Solaris build (P4) JDK-8202822: Add .git to .hgignore (P4) JDK-8196108: Add build support for VS 2015/2017 (P4) JDK-8198306: Add post custom extension hooks to two launchers (P4) JDK-8193016: Add sys/sdt.h and sys/sdt-config.h to linux devkit (for dtrace) (P4) JDK-8202322: AIX: symbol visibility flags not support on xlc 12.1 (P4) JDK-8193189: Allow --boot-jdk to accept a .tar.gz compressed JDK image (P4) JDK-8201320: Allow PrintFailureReports to be turned off (P4) JDK-8205616: Build fails with system headers after 8204572 (P4) JDK-8194645: Build should work with VS 2013 express for 64bit builds (P4) JDK-8203497: Bump Jib format version to 1.2 (P4) JDK-8199103: Can't use COMPARE_BUILD with PATCH from custom root (P4) JDK-8200538: cl : Command line warning D9014 : invalid value '2220' for '/wd'; (P4) JDK-8071469: Cleanup include and exclude of sound native libraries after source code restructure (P4) JDK-8203945: Cleanup nashorn build (P4) JDK-8055194: Cleanup source and makefile logic for libsplashscreen and libjavajpeg after source restructure (P4) JDK-8204091: Configure broken on MIPS when uname returns mipsel or mips64el (P4) JDK-8201536: configure fails compiler check due to bad -m32 flag (P4) JDK-8202383: Custom extensions for jvmti doc (P4) JDK-8199469: Disable generate-jli-classes when building interim-image (P4) JDK-8201229: Disable warnings as errors in aarch64 jib profile (P4) JDK-8199705: Docs.gmk needs to be updated to remove the -html5 option (P4) JDK-8197866: Docs.mk still had a reference to java.se.ee (P4) JDK-8201439: Enable linux-arm-vfp-hflt profile to be configured with jib again (P4) JDK-8202382: Filter docs modules (P4) JDK-8199118: Filtering of filename for microsoft CL broken on newer Cygwin (P4) JDK-8200180: fix a typo in run-test framework documentation (P4) JDK-8201584: Fix configure on SLES 11 after 8201483 (P4) JDK-8205110: Fix xchip warnings with new Solaris toolchain (P4) JDK-8199428: install-file macro fails on filenames with space on Solaris (P4) JDK-8193180: Invalid mapfile entries (P4) JDK-8198627: JDK-8198318 broke readlink testing (P4) JDK-8202210: jlink uses little-endian for big-endian cross-compilation targets (P4) JDK-8202914: Let custom makefile override jmod intput dir locations (P4) JDK-8200727: linux-aarch64 profile should use bundled freetype (P4) JDK-8196585: Make custom extension point additions (P4) JDK-8199668: make/lib cleanup (P4) JDK-8198425: make/Main.gmk Add extra extension/override points to the make file (P4) JDK-8203221: Makefile fixes after Flight Recorder (P4) JDK-8202683: Minimal VM should build cleanly on 64-bit platforms (P4) JDK-8200203: Missing platform definitions for ia64 (P4) JDK-8203946: Move UnpackSecurity.gmk to closed (P4) JDK-8197426: Native tests should always be linked with -lc on solaris (P4) JDK-8201788: Number of make jobs wrong for bootcycle-images target (P4) JDK-8196365: Overriding configure variable from custom hook generates warning (P4) JDK-8204664: PrepareFailureLogs should be done after sequential make targets (P4) JDK-8199416: Remove debug output left over since JDK-8198844 (P4) JDK-8196113: Remove the Compact Profile builds (P4) JDK-8194137: Removed hard coded release numbers in the build (P4) JDK-8199197: Set _NT_SYMBOL_PATH when running tests on windows (P4) JDK-8198569: SetupTextFileProcessing should use sed with 'g' (P4) JDK-8074104: Split BUILD_LIBKRB5 in Lib-java.security.jgss.gmk into two (P4) JDK-8199473: Support Visual Studio BuildTools with VS2017 (P4) JDK-8198323: testing.md not updated for repository layout change (P4) JDK-8199352: The Jib artifact resolver in test lib needs to print better error messages (P4) JDK-8201263: Trailing backslash in VS120COMNTOOLS leads to ugly error message when running tests (P4) JDK-8199266: Update boot and build jdk requirements in configure (P4) JDK-8203924: Zero: bootcycle-images build fails on x86_64 (P4) JDK-8203410: Zero: Disable jfr feature by default install: (P2) JDK-8200740: JEP-179 Macosx dummy builds are failing. (P2) JDK-8201278: JEP-179: builds-promotable bundle builds broken (P2) JDK-8200544: need to create BASIC_DEPRECATED_ARGS for args removed by JEP-179 (P2) JDK-8200739: need to fully restore IBTOOL and ICONV in JEP-179 builds install/install: (P3) JDK-8201283: Unable to install JDK 11 due to Windows Defender SmartScreen (P3) JDK-8198797: Windows: removal of online installers as well associated code javafx/other: (P2) JDK-8195798: ☂ Address dependencies in javafx.* modules on internal APIs of core modules other-libs: (P2) JDK-8189188: JEP 320: Remove the Java EE and CORBA Modules (P4) JDK-8203500: Fix broken links to Specification in "specs" directory (P4) JDK-8190378: Remove the Java EE and CORBA modules other-libs/other: (P3) JDK-8197533: Split java.sql to create module java.transaction.xa (P3) JDK-8196583: Update jib and test jtreg version to 4.2 b12 (P3) JDK-8193838: Update jtreg requiredVersion to 4.2 b11 for JDK 11 and 12 support (P4) JDK-8196081: Add support for customized intellij project templates (P4) JDK-8197113: combine multiple @key tags in jtreg tests (P4) JDK-8199768: jdk/test/lib/compiler/CompilerUtils.java needs to provide more control over compilation performance: (P4) JDK-8189917: Dynamic Constant performance assessment security-libs: (P4) JDK-8205014: com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java failed with "Read timed out" security-libs/java.security: (P2) JDK-8209506: Add Google Trust Services GlobalSign root certificates (P2) JDK-8146293: Add support for RSASSA-PSS Signature algorithm (P2) JDK-8198240: Allow cacerts test to pass when GTECyberTrust root expires (P2) JDK-8205720: KeyFactory#getKeySpec and translateKey throws NullPointerException with Invalid key (P2) JDK-8207318: KeyStore#getInstance(File, LoadStoreParameter) does not load the keystore (P2) JDK-8197441: Signature#initSign/initVerify for an invalid private/public key fails with ClassCastException for SunPKCS11 provider (P3) JDK-8178370: [TEST_BUG] java/security/Signature/SignatureLength.java fails (P3) JDK-8194960: Add a test for trust manager and cacerts keystore sanity (P3) JDK-8195774: Add Entrust root certificates (P3) JDK-8196141: Add GoDaddy root certificates (P3) JDK-8199779: Add T-Systems, GlobalSign and Starfield services root certificates (P3) JDK-8202608: CommonSeeder test needs a white-box testing mechanism to replace the default entropy source (P3) JDK-8191438: jarsigner should print when a timestamp will expire (P3) JDK-8202299: Java Keystore fails to load PKCS12/PFX certificates created in WindowsServer2016 (P3) JDK-8198352: java.util.MissingResourceException: sun.security.util.AuthResources when trying to use com.sun.security.auth.module.UnixLoginModule (P3) JDK-8190933: Links to PKCS standards in Standard Algorithm Names spec should be updated (P3) JDK-8193447: Open-source the Oracle JDK Root Certificates (Phase 2) (P3) JDK-8202837: PBES2 AlgorithmId encoding error in PKCS12 KeyStore (P3) JDK-8200792: PKCS12Attribute#hashCode is always constant -1 (P3) JDK-8189949: Remove Baltimore Cybertrust Code Signing CA (P3) JDK-8203230: Remove cacerts.internal from Oracle JDK (P3) JDK-8191844: Remove SECOM root (secomevrootca1) (P3) JDK-8191031: Remove several Symantec Root CAs (P3) JDK-8193032: Remove terminally deprecated SecurityManager APIs (P3) JDK-8204923: Restore Symantec root verisignclass2g2ca (P3) JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized (P3) JDK-8201815: Switch to Mozilla Public Suffix List in Hostname Checking (P3) JDK-8205927: Update src/java.base/share/legal/public_suffix.md to match the actual file version (P4) JDK-8202419: Avoid creating Permission constants early (P4) JDK-8195119: Fine-tune output text in keytool (P4) JDK-8152821: Merge jdk.internal.misc.JavaSecurityAccess and jdk.internal.misc.JavaSecurityProtectionDomainAccess shared secrets (P4) JDK-8190229: Non-ASCII characters in java.security file after 8186093 (P4) JDK-8189760: sun/security/ssl/CertPathRestrictions/TLSRestrictions.java failed with unexpected Exception intermittently (P4) JDK-8144806: sun/security/tools/keytool/standard.sh fails intermittently at deleting x.jks (P4) JDK-8202816: Update JarSigning.keystore (P4) JDK-8196414: Update ProviderVersionCheck.java to pass on updated JDK versions security-libs/javax.crypto: (P2) JDK-8205445: Add RSASSA-PSS Signature support to SunMSCAPI (P2) JDK-8198898: Compilation errors in jdk.crypto.mscapi with VS 2017 (P2) JDK-8205478: KeyAgreement#generateSecret is not reset for XDH based algorithm (P2) JDK-8178374: Problematic ByteBuffer handling in CipherSpi.bufferCrypt method (P2) JDK-8206915: XDH TCK issues (P3) JDK-7007966: Add Brainpool ECC support (RFC 5639) (P3) JDK-8203228: Branch-free output conversion for X25519 and X448 (P3) JDK-8199296: ChaCha20 and Poly1305 algorithms testing criteria: code coverage (P3) JDK-8199293: ChaCha20 and Poly1305 algorithms testing criteria: pass rate (P3) JDK-8199297: ChaCha20 and Poly1305 algorithms testing criteria: public API coverage (P3) JDK-8199294: ChaCha20 and Poly1305 algorithms testing criteria: test stability (P3) JDK-8153029: ChaCha20 Cipher Implementation (P3) JDK-8200219: Develop negative tests for new elliptic curves: curve25519 and curve448 (P3) JDK-8184359: Develop new tests for using new elliptic curves: curve25519 and curve448 (P3) JDK-8181594: Efficient and constant-time modular arithmetic (P3) JDK-8171277: Elliptic Curves for Security in Crypto (P3) JDK-8181595: JEP 324: Key Agreement with Curve25519 and Curve448 (P3) JDK-8153028: JEP 329: ChaCha20 and Poly1305 Cryptographic Algorithms (P3) JDK-8200222: Key Agreement with Curve25519 and Curve448 API testing criteria: code coverage (P3) JDK-8200220: Key Agreement with Curve25519 and Curve448 API testing criteria: pass rate (P3) JDK-8200223: Key Agreement with Curve25519 and Curve448 API testing criteria: public API coverage (P3) JDK-8200221: Key Agreement with Curve25519 and Curve448 API testing criteria: test stability (P3) JDK-8205427: KeyAgreement#init throws InvalidAlgorithmParameterException for null param for XDH (P3) JDK-8199388: Test development for ChaCha20 and Poly1305 algorithms (P3) JDK-8184357: Test Plan for ChaCha20 and Poly1305 algorithms (P3) JDK-8181611: Test plan for Key Agreement with Curve25519 and Curve448 (P4) JDK-8199292: Initial test plan for ChaCha20 and Poly1305 algorithms (P4) JDK-8193262: JNI array not released in libsunmscapi convertToLittleEndian security-libs/javax.crypto:pkcs11: (P3) JDK-8164639: Configure PKCS11 tests to use user-supplied NSS libraries (P4) JDK-8194864: Outputs more details for PKCS11 tests if the NSS lib version cannot be determined (P4) JDK-8195607: sun/security/pkcs11/Secmod/TestNssDbSqlite.java failed with "NSS initialization failed" on NSS 3.34.1 (P5) JDK-8203182: Release session if initialization of SunPKCS11 Signature fails security-libs/javax.net.ssl: (P1) JDK-8207317: SSLEngine negotiation fail exception behavior changed from fail-fast to fail-lazy (P2) JDK-8206929: Check session context for TLS 1.3 session resumption (P2) JDK-8205111: Develop new Test to verify different key types for supported TLS protocols. (P2) JDK-8145252: JEP 332: Transport Layer Security (TLS) 1.3 (P2) JDK-8206178: New TLS 1.3 standard names (P2) JDK-8206176: Remove the temporary tls13VN field (P2) JDK-8206355: SSLSessionImpl.getLocalPrincipal() throws NPE (P2) JDK-8207237: SSLSocket#setEnabledCipherSuites is accepting empty string (P2) JDK-8208166: Still unable to use custom SSLEngine with default TrustManagerFactory after JDK-8207029 (P2) JDK-8207009: TLS 1.3 half-close and synchronization issues (P2) JDK-8196584: TLS 1.3 Implementation (P2) JDK-8207029: Unable to use custom SSLEngine with default TrustManagerFactory after updating to JDK 11 b21 (P3) JDK-8203686: Add JDK 11 major version to javax/net/ssl/compatibility/JdkRelease.java (P3) JDK-8205984: javax/net/ssl/compatibility/Compatibility.java failed to access port log file (P3) JDK-8199645: javax/net/ssl/SSLSession/TestEnabledProtocols.java failed with Connection reset (P3) JDK-8208496: New Test to verify concurrent behavior of TLS. (P3) JDK-8207223: SSL Handshake failures are reported with more generic SSLException (P3) JDK-8206189: sun/security/pkcs12/EmptyPassword.java fails with Sequence tag error (P4) JDK-8199018: Test crypto provider not registering security-libs/javax.security: (P3) JDK-8191139: Remove deprecated javax.security.auth.Policy API security-libs/javax.xml.crypto: (P3) JDK-8177334: Update xmldsig implementation to Apache Santuario 2.1.1 security-libs/jdk.security: (P3) JDK-8199154: Accessibility issues in jdk.security.auth (P4) JDK-8196823: jarsigner should not create a signed jar if the signing fails security-libs/org.ietf.jgss: (P3) JDK-8072996: Deprecate stream-based GSSContext methods (P3) JDK-8187218: GSSCredential.getRemainingLifetime() returns negative value for TTL > 24 days. (P3) JDK-8197518: Kerberos krb5 authentication: AuthList's put method leads to performance issue (P4) JDK-8194073: Invalid SunNativeProvider.INSTANCE initialization (P4) JDK-8200468: Port the native GSS-API bridge to Windows security-libs/org.ietf.jgss:krb5: (P3) JDK-8201627: Kerberos sequence number issues (P3) JDK-8200152: KerberosString should use UTF-8 by default (P3) JDK-8014628: Support AES Encryption with HMAC-SHA2 for Kerberos 5 defined in RFC 8009 (P4) JDK-8177398: Exclude dot files ending with .conf from krb5.conf's includedir (P4) JDK-8194630: GSS: Uninitialized cb->initiator_address when using channel binding with native kerberos (P4) JDK-8201867: Kerberos keytabs with holes in certain places are parsed incorrectly (P4) JDK-8186228: sun/security/krb5/auto/KdcPolicy.java fails with "java.lang.Exception: Does not match. Output is c30000c30000c30000" (P4) JDK-8200101: sun/security/krb5/auto/Renewal.java fails intermittently specification/language: (P4) JDK-8206943: 15.27.1: Allow var in lambda parameters (P4) JDK-8204255: 15.27.4: Clarify the identity of the result of evaluating a lambda expression (P4) JDK-8177019: JLS changes for Nestmates (P5) JDK-4660984: 16.2.12: Clarify DU/DA analysis for loop containing break specification/vm: (P3) JDK-8199051: 5.4.3.6: Require first parameter type of a condy bootstrap to be Lookup (P4) JDK-8098577: 6.5: invokevirtual must specify selection when resolved method is in interface (P4) JDK-8283910: JVMS changes for Dynamic Class-File Constants (P4) JDK-8177020: JVMS changes for Nestmates (P5) JDK-8078636: 5.4.2: The term "inherited" is not defined tools: (P2) JDK-8186209: Tool support for ConstantDynamic (P3) JDK-8199871: Deprecate pack200 and unpack200 tools (P3) JDK-8205455: jdeprscan issues annotation processor warning regarding RELEASE_10 (P3) JDK-8205116: jdeps --system $java.home fails with IAE (P3) JDK-8193259: JEP 323: Local-Variable Syntax for Lambda Parameters (P3) JDK-8196993: Resolve disabled warnings for libunpack (P3) JDK-8203891: Upgrade JOpt Simple to 5.0.4 (P4) JDK-8189102: All tools should support -?, -h and --help (P4) JDK-8205403: Deprecate pack200 specification (P4) JDK-8201259: Fix warning with VS2017 in jdk.pack (P4) JDK-8194308: jdeprscan will need updates to deal with the removal of the Java EE modules (P4) JDK-8204584: jdeps generates illegal dot file containing ranksep=0,600000 (P4) JDK-8200752: JEP 336: Deprecate the Pack200 Tools and API tools/jar: (P4) JDK-8191533: jar --describe-module prints service provider class names in lower case tools/javac: (P1) JDK-8198479: JDK build is broken by 8194892 (P2) JDK-8204322: "+=" applied to String operands can provoke side effects (P2) JDK-8199910: Compiler crashes with -g option and variables of intersection type inferred by `var` (P2) JDK-8202832: cycle detection depends on ordering of requires directives (P2) JDK-8201554: Disable failing tier1 test for JDK-8201498 (P2) JDK-8202387: javac --release 11 not supported (P2) JDK-8189747: JDK9 javax.lang.model.util.Elements#getTypeElement regressed 1000x in performance. (P2) JDK-8205563: modules/AnnotationProcessing.java failed testGenerateSingleModule (P2) JDK-8205052: No compilation error thrown when no valid parameterization exists for functional interface type (P2) JDK-8198563: Test langtools/tools/javac/analyzer/AnonymousInAnonymous.java failing after JDK-8198502 (P2) JDK-8201498: test/langtools/tools/javac/diags/CheckExamples.java 6 errors occurred (P3) JDK-8194892: (Original) Add compiler support for local-variable syntax for lambda parameters (P3) JDK-8198512: Add compiler support for local-variable syntax for lambda parameters (P3) JDK-8199194: Add javac support for preview features (P3) JDK-8194998: broken error message for subclass of interface with private method (P3) JDK-8194296: Check copyright of files in make/langtools/tools (P3) JDK-8207032: Compilation succeeds without checking readability when --add-exports used (P3) JDK-8197439: Crash with -XDfind=lambda for anonymous class in anonymous class. (P3) JDK-8200301: deduplicate lambda methods (P3) JDK-8202372: Diagnostic with incorrect line info generated when compiling lambda expression (P3) JDK-8151850: eliminate javax.tools.FileManagerUtils (P3) JDK-8148354: Errors targeting functional interface intersection types (P3) JDK-8198628: further simplifications to lambda classification at JavacParser (P3) JDK-8204630: Generating an anonymous class with Filer#createClassFile causes an NPE in JavacProcessingEnvironment (P3) JDK-8201194: Handle local variable declarations in lambda deduplication (P3) JDK-8193717: Import resolution performance regression in JDK 9 (P3) JDK-8189765: Improve error reporting for compiling against package not visible due to modules (P3) JDK-8196519: Incomplete classpath causes infinite recursion in Resolve.isAccessible (P3) JDK-8198315: Incomplete classpath causes NPE in TransTypes (P3) JDK-8199744: Incorrect compiler message for ReceiverParameter in inner class constructor (P3) JDK-8195986: Incorrect javac -h output with annotation processing and missing classes (P3) JDK-8193302: Javac AssertionError: typeSig ERROR on usage of @Generated (P3) JDK-8198378: javac crash when checking imports and a broken class is present (P3) JDK-8189335: javac exception when referencing private inner class with same name as normal class with dollar_1 (P3) JDK-8198314: javac hidden options violate standard syntax for options (P3) JDK-8202597: javac is not inducing a notional interface if Object appears in an intersection type (P3) JDK-8203838: javac performance regression in 11+11 (P3) JDK-8194978: Javac produces dead code for try-with-resource (P3) JDK-8201440: javac should create unique DynamicMethodSymbols at LambdaToMethod (P3) JDK-8203436: javac should fail early when emitting illegal signature attributes (P3) JDK-8190452: javac should not add MethodParameters attributes to v51 and earlier class files (P3) JDK-8186688: javax.lang.model.util.Elements.hides does not work correctly with interfaces (P3) JDK-8192920: JEP 330: Launch Single-File Source-Code Programs (P3) JDK-8202843: langtools ant build fails (P3) JDK-8200355: local variable inference regression test generates classfile in test folder (P3) JDK-8198552: Multiple javac plugins do not work at the same time. (P3) JDK-8199327: nuke var type name after a lambda has been accepted (P3) JDK-8187296: Prepare for classfile version 55 and javac "release" update (P3) JDK-8195598: Reference to overloaded method is ambiguous with 3 methods but works with 2 (P3) JDK-8178150: Regression in logic for handling inference stuck constraints (P3) JDK-8193779: remove option to force the generation of indy for all lambdas once ASM understands condy (P3) JDK-8196403: remove the remaining use of string keys for errors and warnings in the compiler (P3) JDK-8200166: Repeating annotations refering to to-be-generated classes don't work. (P3) JDK-8203486: skip type inference for non functional interface components of intersection types (P3) JDK-8203892: Target interface added as marker interface in calls to altMetafactory (P3) JDK-8201512: Test plan for JEP 330: Launch Single-File Source-Code Programs (P3) JDK-8203398: Test test/langtools/tools/javac/options/release/ReleaseOptionCurrent.java writes into the source directory (P3) JDK-8201251: The tests for JDK-8187247 should be under test/langtools (P3) JDK-8196048: thrown type variables should be roots in the minimum inference graph (P3) JDK-8202178: type.getKind() for var is None instead of Error (P3) JDK-8057650: uniform error diagnostics for inconsistent inherited method signatures (P4) JDK-8173382: Add -source 11 and -target 11 to javac (P4) JDK-8203679: AssertionError in DeferredAttr with parenthesized method reference (P4) JDK-8205442: Avoid hard-coding --source value in SourceLauncherTest.java (P4) JDK-8152616: com.sun.tools.javac.tree.Pretty generates nested comments for enum (P4) JDK-8204610: Compiler confused by parenthesized "this" in final fields assignments (P4) JDK-8196618: Create API to list supported values for javac --release option (P4) JDK-8198502: Exception at runtime due to lambda analyzer reattributes live AST (P4) JDK-8193216: Filer should warn if processors redefine symbols from the classpath or sourcepath (P4) JDK-8189146: Have use of "var" in 9 and earlier source versions issue a warning for type declarations (P4) JDK-8204674: Inconsistent lambda parameter span (P4) JDK-8205913: Inconsistent source code model (P4) JDK-8177486: Incorrect handling of mandated parameter names in MethodParameters attributes (P4) JDK-8194268: Incorrect parameter names for synthetic methods (P4) JDK-8195293: Issue more comprehensive warnings for use of "var" in earlier source versions (P4) JDK-8179373: javac -verbose logs the class path multiple times (P4) JDK-8194893: javac -verbose prints wrong paths for output files (P4) JDK-8203813: javac accepts an illegal name as a receiver parameter name (P4) JDK-8200199: javac suggests to use var even when var is used (P4) JDK-8007720: Names are not load correctly for method parameters if the parameters have annotations (P4) JDK-8194932: no ambuguity error is emitted if classfile contains two identical methods with different return types (P4) JDK-8203488: Remove error generation from TransTypes (P4) JDK-8194141: Remove JDK9Wrappers (P4) JDK-8202157: remove the use of string keys at InapplicableMethodException (P4) JDK-8196074: Remove uses of loose type equality tests (P4) JDK-8201281: Truncated error message with Incompatible : null (P4) JDK-8203338: Unboxing in return from lambda miscompiled to throw ClassCastException (P4) JDK-8202141: Unique symbols for .class (P4) JDK-8196623: Update JavaBaseTest.java to be version agnostic (P4) JDK-8196627: Update MultiReleaseJarAwareSJFM.java to be version agnostic (P4) JDK-8196433: use the new error diagnostic approach at javac.Main tools/javadoc(tool): (P2) JDK-8204303: Add redirect for overview-summary.html (P2) JDK-8182765: HTML5 must be the default javadoc codegen mode in the near future (P2) JDK-8204330: Javadoc IllegalArgumentException: HTML special chars in constant value (P2) JDK-8204321: javadoc tests fail after JDK-8203780 (P2) JDK-8194651: javadoc: mark the com.sun.javadoc API for removal (P2) JDK-8207190: JDK 11 javadoc generates bad code example (P2) JDK-8025091: VisibleMemberMap.java possible performance improvements (P3) JDK-8149565: -locale option issues (P3) JDK-8202614: Add ability to validate links in JavadocTester (P3) JDK-8199196: Add javadoc support for preview features (P3) JDK-8187288: bad (no) wrapping for modifier and type column (P3) JDK-8195805: Doclet incorrectly updates all attributes in tags when relocating links (P3) JDK-8199268: docs/api/jdk.javadoc/com/sun/javadoc/package-summary.html contain low contrast text. (P3) JDK-8201396: fix broken links generated by javadoc doclet (P3) JDK-8202947: Fix minor issues with taglets (P3) JDK-8196201: Generate pages to list all classes and all packages in javadoc output (P3) JDK-8196200: Implement a navigation builder in javadoc (P3) JDK-8196913: javadoc does not (over)write stylesheet.css (P3) JDK-8202627: javadoc generates broken links to deprecated items when -nodeprecated is used (P3) JDK-8202624: javadoc generates references to enum constructors, which are not documented (P3) JDK-8203176: javadoc handles non-ASCII characters incorrectly. (P3) JDK-8198522: Javadoc search broken after output files organization for modules (P3) JDK-8190876: javadoc search on "java.se" shows "java.se" the last one among other modules (P3) JDK-8199278: Javadoc search results does not link to anchors on a page (P3) JDK-8203780: javadoc should be updated to use jquery 1.12.4 and jszip v3.1.5 (P3) JDK-8204666: javadoc should be updated to use jQuery 3.3.1 (P3) JDK-8196202: Javadoc should not generate frames by default (P3) JDK-8205160: jQuery UI , jQuery-migrate, and jQuery license file to be updated to the revision present. (P3) JDK-8190875: modules not listed in overview/index page (P3) JDK-8199307: NPE in jdk.javadoc.internal.doclets.toolkit.util.Utils.getLineNumber (P3) JDK-8188248: NullPointerException on generic methods (P3) JDK-8195795: Organize output files by module/package, not just package (P3) JDK-8195796: Reduce the size of relative URLs in generated docs (P3) JDK-8201622: Reduce unnecessary Package.complete() calls in javadoc (P3) JDK-8196736: Refactor HelpWriter and properties (P3) JDK-8196027: Remove "Prev" and "Next" links from the javadoc navigation (P3) JDK-8201817: Taglet.init should be called with the "primary" doclet (P3) JDK-8207213: The help-doc.html generated by the doclet is incomplete (P3) JDK-8185740: The help-doc.html generated by the doclet is outdated (P3) JDK-8199893: the javadoc tool generates pages with a low constrast (P3) JDK-8198890: The standard doclet incorrectly produces wrong method signatures in certain cases. (P3) JDK-8200094: Turkish locale reports NPE: No enum constant com.sun.source.doctree.DocTree.Kind.SİNCE (P3) JDK-8194955: Warn when default HTML version is used (P4) JDK-8205148: Turn off logging in jQuery-migrate (P4) JDK-8199902: {@docRoot} references need to be updated to reflect new module/package structure tools/jlink: (P3) JDK-8196988: Resolve disabled warnings for libjimage (P3) JDK-8161348: Several tools/jlink tests failed in "-Xcomp" mode due to time out (P3) JDK-8203223: Signed integer overflow in ImageStrings::hash_code (libjimage.so) (P3) JDK-8178867: tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java failed to clean up files (P4) JDK-8198417: Exclude tools/jimage/JImageExtractTest.java and tools/jimage/JImageListTest.java on Windows (P4) JDK-8194734: Handle to jimage file inherited into child processes (win) (P4) JDK-8170120: jimage throws IOException when the given file is not a jimage file (P4) JDK-8194922: jlink --exclude-resources should never exclude module-info.class (P4) JDK-8196310: jlink --suggest-providers fails with missing resource if --output specified (P4) JDK-8202583: Remove experimental ClassForNamePlugin (P4) JDK-8205926: Support invokeSpecialIFC in GenerateJLIClassesPlugin (P4) JDK-8202810: tools/jlink/JLinkPluginsTest.java fails with Error: unknown option: --class-for-name tools/jshell: (P2) JDK-8195789: Building of test/langtools/jdk/jshell/VariablesTest.java may fail (P2) JDK-8202690: jdk/jshell/ToolBasicTest.java failed in testOpenFileOverHttp() and testOpenLocalFileUrl() (P3) JDK-8199193: jshell tool: Add support for preview features (P3) JDK-8198573: JShell: class replace loses instances (P3) JDK-8191842: JShell: Inferred type information is lost when assigning types to a "var" (P3) JDK-8198801: JShell: user exception chained cause not retained (P3) JDK-8203827: Upgrade JLine to 2.14.6 (P4) JDK-8188894: jdk/jshell/ToolShiftTabTest.java failed with IllegalStateException (P4) JDK-8199762: JShell API: Failed to detect override when snippet to be overridden has been changed before (P4) JDK-8196133: JShell crashes when attempting to use bad source file in class path (P4) JDK-8202520: JShell tests: move intermittently failing tests to tier2 (P4) JDK-8199912: jshell tool: /open from URI (P4) JDK-8166232: jshell tool: cannot access previous history (P4) JDK-8202599: Mark intermittently failing jshell tests tools/launcher: (P3) JDK-8205916: [test] Fix jdk/tools/launcher/RunpathTest to handle both, RPATH and RUNPATH (P3) JDK-8198793: Add launcher support for preview features (P3) JDK-8201274: Launch Single-File Source-Code Programs (P3) JDK-8205438: Re-enable shebang tests in test/jdk/tools/launchers/SourceMode.java (P3) JDK-8196990: Resolve disabled warnings for libjli (P3) JDK-8204648: test/jdk/tools/launchers/SourceMode.java fails with long shebang line (P4) JDK-8193819: Error message when module does not have a ModuleMainClass attribute is confusing (P4) JDK-8195663: Java launcher HelpFlagsTest.java fails with java.lang.AssertionError (P4) JDK-8199858: solaris-x86_64 : unpack200 fails linking with SS12u4 (P4) JDK-8186009: tools launcher test AddExportsAndOpensInManifest.java fails intermittently: AccessDeniedException (P4) JDK-8195824: tools/launcher/HelpFlagsTest.java fails with java.lang.AssertionError xml/javax.xml.parsers: (P4) JDK-8038043: Xerces Update: XInclude update xml/javax.xml.transform: (P4) JDK-8202426: NPE thrown by Transformer when XMLStreamReader reports no xml attribute type xml/javax.xml.validation: (P4) JDK-8202915: [JAXP] Performance enhancements and cleanups in com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator xml/javax.xml.xpath: (P4) JDK-8198548: Initialization race in com.sun.org.apache.xerces.internal.impl.xpath.regex.Token.getRange() on Token.categories xml/jaxp: (P3) JDK-8201138: Defect in XMLEventReader.getElementText() may cause data to be skipped, duplicated or otherwise result in a ClassCastException (P3) JDK-8193830: Xalan Update: Xalan Java 2.7.2 (P4) JDK-8195989: JDK-8186080 merge add back @LastModified removed by JDK-8193586 (P4) JDK-8199792: Wrong license header in XMLLimitAnalyzer.java xml/org.xml.sax: (P3) JDK-6857903: SAXException.initCause() does not correctly set Exception