RELEASE NOTES FOR: 13 ==================================================================================================== Notes generated: Wed Jul 01 06:08:01 CEST 2020 JIRA Query: project = JDK AND (status in (Closed, Resolved)) AND (resolution not in ("Won't Fix", Duplicate, "Cannot Reproduce", "Not an Issue", Withdrawn)) AND (labels not in (release-note, testbug, openjdk-na, testbug) OR labels is EMPTY) AND (summary !~ 'testbug') AND (summary !~ 'problemlist') AND (summary !~ 'problem list') AND (summary !~ 'release note') AND (issuetype != CSR) AND fixVersion = 13 Acquiring pages (2210 total): ............................................. done Loading issues (2210 total): ............................................. done Resolving issues (2210 total): ............................................ done Resolving parents (2210 total): ............................................ done JIRA Query: project = JDK AND issuetype = JEP AND fixVersion = 13 ORDER BY summary ASC Acquiring pages (5 total): . done Loading issues (5 total): . done Resolving issues (5 total): done Resolving parents (5 total): done Filtered 193 issues carried over, 2001 pushes left. JDK-8217427 (dc) nio/channels/DatagramChannel/UseDGWithIPv6.java fails without IPv6 JDK-8215238 (jdeps) update jdk8_internals.txt per the removal of javafx, corba, EE modules JDK-8212828 (process) Provide a way for Runtime.exec to use posix_spawn on linux JDK-8215374 32-bit build failures after JDK-8181143 (Introduce diagnostic flag to abort VM on too long VM operations) JDK-8216180 [AOT] compiler/intrinsics/bigInteger/TestMulAdd.java crashed with AOT enabled JDK-8215313 [AOT] java/lang/String/Split.java fails with AOTed java.base JDK-8217678 [AOT] jck Math/IncrementExact and Math/DecrementExact tests fail when test classes are AOTed JDK-8218197 [failurehandler] parent processes shouldn't be killed till their children are handled JDK-8215314 [Graal] Enable org.graalvm.compiler.core.test.CountedLoopTest JDK-8215375 [Graal] jck:vm/jvmti/Exception/excp001/excp00101 fails in Graal as JIT mode and -Xcomp mode JDK-8196568 [Graal] LongMulOverflowTest.java fails with "runTestOverflow() did not overflow" JDK-8216151 [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.org.graalvm.compiler.debug JDK-8215317 [GRAAL] unit test CheckGraalIntrinsics failed after 8213754 JDK-8158646 [jittester] generated tests may not compile by javac JDK-8067250 [mlvm] vm/mlvm/mixed/stress/regression/b6969574 fails and perf regression JDK-8216376 [PPC64] Possibly unreliable stack frame resizing in template interpreter JDK-8214520 [TEST_BUG] sun/security/mscapi/nonUniqueAliases/NonUniqueAliases.java failed with incorrect jtreg tags order JDK-8215342 [Zero] Build fails after JDK-8200613 JDK-8215100 AArch64: fix compareTo intrinsic with four-character Latin/Unicode JDK-8215202 AArch64: jtreg test test/jdk/sun/nio/cs/FindEncoderBugs.java fails JDK-8209414 AArch64: method handle invocation does not respect JVMTI interp_only mode JDK-8215879 Aarch64: ReservedStackAccess may leave stack guard in inconsistent state JDK-8205421 AARCH64: StubCodeMark should be placed after alignment JDK-8213134 AArch64: vector shift failed with MaxVectorSize=8 JDK-8217467 Access barriers are missing in C2 intrinsic for Base64 JDK-8214583 AccessController.getContext may return wrong value after JDK-8212605 JDK-8217438 Adapt tools//launcher/Test7029048.java for AIX JDK-8215322 add @file support to jaotc JDK-8196600 Add example to show how to have TrustManager take the validity dates of trust anchors into account JDK-8216577 Add GlobalSign's R6 Root certificate JDK-8215300 additional changes to constants API JDK-8202286 Allocation of old generation of Java heap on alternate memory devices JDK-8211425 Allocation of old generation of java heap on alternate memory devices - G1 GC JDK-8211424 Allocation of old generation of java heap on alternate memory devices - Parallel GC JDK-8218662 Allow 204 responses with Content-Length:0 JDK-8216280 Allow later Symantec Policy distrust date for two Apple SubCAs JDK-8215395 Allow null oops in Dictionary and JNIHandle verification JDK-8215318 Amend the Standard Algorithm Names specification to clarify that names can be defined in later versions JDK-8215773 applications/kitchensink/Kitchensink.java crash with "assert(ZAddress::is_marked(addr)) failed: Should be marked" JDK-8214512 ARM32: Jtreg test compiler/c2/Test8062950.java fails on ARM JDK-8215889 assert(!_unloading) failed: This oop is not available to unloading class loader data with ZGC JDK-8210392 assert(Compile::current()->live_nodes() < Compile::current()->max_node_limit()) failed: Live Node limit exceeded limit JDK-8213825 assert(false) failed: Non-balanced monitor enter/exit! Likely JNI locking JDK-8214862 assert(proj != __null) at compile.cpp:3251 JDK-8217230 assert(t == t_no_spec) failure in NodeHash::check_no_speculative_types() JDK-8215292 Back out changes for node- and link- local ipv6 multicast address JDK-8215380 Backout accidental change to String::length JDK-8215195 Bad HTML/Accessibility in jni/functions.html JDK-8215291 Broken links when generating from project without modules JDK-8215898 Build broken on 32-bit after JDK-8211425 JDK-8215897 Build broken on zero after JDK-8211425 JDK-8216135 C2 assert(!had_error) failed: bad dominance JDK-8217359 C2 compiler triggers SIGSEGV after transformation in ConvI2LNode::Ideal JDK-8215044 C2 crash in loopTransform.cpp with assert(cl->trip_count() > 0) failed: peeling a fully unrolled loop JDK-8215575 C2 crash: assert(get_instanceKlass()->is_loaded()) failed: must be at least loaded JDK-8215757 C2: PhaseIdealLoop::create_new_if_for_predicate() computes wrong IDOM JDK-8215265 C2: range check elimination may allow illegal out of bound access JDK-8216427 ciMethodData::load_extra_data() does not always unpack the last entry JDK-8216176 Clarify the singleton description in j.t.c.JapaneseEra class JDK-8217892 Clarify the support for the new Japanese era in java.time.chrono.JapaneseEra JDK-8210561 Command-line help wrong for javac --module JDK-8216541 CompiledICHolders of VM locked unloaded nmethods are released too late JDK-8215309 Convert package.html files to package-info.java files JDK-8211698 Crash in C2 compiled code during execution of double array heavy processing code JDK-8216965 crash in freetypeScaler.c CopyBW2Grey8 JDK-8215123 Crash in runtime image built with jlink --compress=2 JDK-8207922 ctw of jdk.security.auth failed with "Unexpected zero exit codebefore finishing all compilations" JDK-8076190 Customizing the generation of a PKCS12 keystore JDK-8211093 Default logging.properties sets log level for com.xyz.foo JDK-8214892 Delayed starting of debugging via jcmd JDK-8218025 disable pop_frame and force_early_return caps for Graal JDK-8215356 Disable x86_32 Shenandoah build to avoid hotspot/tier1 failures JDK-8215296 do not disable c99 on Solaris JDK-8214741 docs/index.html has no title or copyright JDK-8049711 document com.sun.security.jgss.inquiretype. for GSSAPI mechanism JDK-8143368 Document JarSigner and X509CertificateBuilder JDK-8073643 Document the system property jdk.tls.rejectClientInitiatedRenegotiation JDK-8215280 Double click on titlebar not working for Frame with extended state set to MAXIMIZED_BOTH JDK-8215724 Epsilon: ArrayStoreExceptionTest.java fails; missing arraycopy check JDK-8215583 Exclude runtime/handshake/HandshakeWalkSuspendExitTest.java JDK-8218020 Fix version number in mesa.md 3rd party legal file JDK-8215548 G1PeriodicGCSystemLoadThreshold needs to be a double JDK-8217666 gc/nvdimm/* should not be included any tiers JDK-8213695 gc/TestAllocateHeapAtMultiple.java is slow in some configs JDK-8215500 ICRefillVerifierMark does not set the provided verfier as current JDK-8215491 ICStubInterface::finalize finds zombie nmethod with ZGC concurrent class unloading JDK-8219151 Illegal instruction exception on JDK 12 due to incorrect CPU feature bits JDK-8208184 IllegalArgumentException while invoking code completion on netbeans IDE JDK-8215159 Improve initial setup of system Properties JDK-8215175 Inconsistencies in JFR event metadata JDK-8214827 Incorrect call ClassLoaders.toFileURL("jrt:/java.compiler") JDK-8181143 Introduce diagnostic flag to abort VM on too long VM operations JDK-8215510 j.l.c.ClassDesc is accepting descriptors not allowed by the spec JDK-7092821 java.security.Provider.getService() is synchronized and became scalability bottleneck JDK-8212233 javadoc fails on jdk12 with "The code being documented uses modules but the packages defined in $URL are in the unnamed module." JDK-8215364 JavaFX crashes on Ubuntu 18.04 with Wayland while using Swing-FX interop JDK-8215205 javaVFrame much slower than vframeStream JDK-8203687 javax/net/ssl/compatibility/Compatibility.java supports TLS 1.3 JDK-8215319 jck lang/INTF/intf049/intf04901 fails in Graal as JIT mode with -Xcomp and AOTed Graal JDK-8215369 JCStress pollute /var/tmp with temporary files. JDK-8218411 JDK 12 L10n resource file update msg drop 20 JDK-8215994 JDK 12 l10n resource file update - msg drop 10 JDK-8215237 jdk.jfr.Recording javadoc does not compile JDK-8215244 jdk/jshell/ToolBasicTest.java testHistoryReference failed JDK-8215451 JNI IsSameObject should not keep objects alive JDK-8215243 JShell tests failing intermitently with "Problem cleaning up the following threads:" JDK-8215099 jshell tool: /help representation of ctrl/meta characters inconsistent JDK-8215438 jshell tool: Ctrl-D causes EOF JDK-8215397 jsig.c missing classpath exception JDK-8215947 JVM crash with -XX:+DumpSharedSpaces JDK-8167276 jvmci/compilerToVM/MaterializeVirtualObjectTest.java fails with -XX:-EliminateAllocations JDK-8215694 keytool cannot generate RSASSA-PSS certificates JDK-8216271 Make AllocateOldGenAt an unsupported option on AIX. JDK-8215239 Make deletes images/jdk/bin/java if something goes wrong JDK-8215304 Make target "docs-jdk-index" has unnecessary dependencies JDK-8216549 Mismatched unsafe access to non escaping object fails JDK-8216322 Missing since information in deprecation of constructor visitors JDK-8218134 Modify the jQuery.md file to reflect the exact jQuery license content. JDK-8214696 Module class should be filtered by core reflection JDK-8215301 Module-summary page is unreadably wide JDK-8217657 Move the test for default value of jdk.includeInExceptions into own test JDK-8207404 MulticastSocket tests failing on AIX JDK-8213782 NullPointerException in sun.security.ssl.OutputRecord.changeWriteCiphers JDK-8211034 OnStackReplacePercentage option checking has bugs JDK-8214074 Optimize Ghash using AVX instructions JDK-8215635 Pandoc check in Docs.gmk does not work on Windows JDK-8215177 pandoc should use JDK-8215308 pandoc-html-manpage-filter.js does not work for [un]pack200 JDK-8213754 PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace JDK-8215262 PPC64: FMA Vectorization on PPC64 JDK-8214707 Prevent GCC 8 from reporting error in ClassLoader::file_name_for_class_name() JDK-8215284 Reduce noise induced by periodic task getFileSize() JDK-8215888 Register to register spill may use AVX 512 move instruction on unsupported platform. JDK-8215410 Regression test for JDK-8214994 JDK-8215681 Remove compiler support for Raw String Literals from JDK 12 JDK-8215648 remove equals and hashCode implementations from j.l.i.VarHandle JDK-8220542 Remove references to policytool from documentation JDK-8215489 Remove String::align JDK-8211068 rmic does not support classes compiled with the option --enable-preview JDK-8216021 RunTest.gmk might set concurrency level to 1 on Windows JDK-8213299 runtime/appcds/jigsaw/classpathtests/EmptyClassInBootClassPath.java failed with java.lang.NoSuchMethodException JDK-8202884 SA: Attach/detach might fail on Linux if debugee application create/destroy threads during attaching JDK-8214226 SA: Incorrect BCI and Line Number with jstack if the top frame is in the interpreter JDK-8076035 Security Guide Updates for LoginModule loading change (JDK-8047789) JDK-8217043 Shenandoah: SIGSEGV in Type::meet_helper() at barrier expansion time JDK-8216482 Shenandoah: typo in ShenandoahBarrierSetC2::clone_barrier_at_expansion() causes failed compilations JDK-8217042 Shenandoah: write barrier on backedge of strip mined loop causes c2 crash at expansion time JDK-8216314 SIGILL in CodeHeapState::print_names() JDK-8215220 Simplify Shenandoah task termination in aborted paths JDK-8209333 Socket reset issue for TLS 1.3 socket close JDK-8210669 Some launcher tests assume a pre-JDK 9 run-time image layout JDK-8216490 Spammy periodic GC log message contains random time stamp with periodic gc disabled JDK-8214339 SSLSocketImpl erroneously wraps SocketException JDK-8215493 String::indent inconsistency with blank lines JDK-8215112 String::transform spec clarification JDK-8152724 Sum of eden before GC and current survivor capacity may be larger than heap size JDK-8214096 sun.security.util.SignatureUtil passes null parameter, so JCE validation fails JDK-8214937 sun/security/tools/jarsigner/warnings/NoTimestampTest.java failed due to unexpected expiration date JDK-8216050 Superword optimization fails with assert(0 <= i && i < _len) failed: illegal index JDK-8216546 Support new Japanese era in java.lang.Character for Java SE 11 JDK-8214329 SwingMark SubMenus 9% regression in 12-b19 on Linux client JDK-8215326 Test java/util/concurrent/ConcurrentHashMap/ToArray.java hangs after j.u.c updates JDK-8216316 Tests fail due to too low specified TLAB size JDK-8216045 The size of key_exchange may be wrong on FFDHE JDK-8215443 The use of TransportContext.fatal() leads to bad coding style JDK-8215921 There is no change when select different Foreground and Background by mouse. JDK-8215555 TieredCompilation C2 threads can excessively block handshakes JDK-8215000 tools/launcher/JliLaunchTest.java fails on Windows JDK-8216532 tools/launcher/Test7029048.java fails (Solaris) JDK-8165675 Trace event for thread park has incorrect unit for timeout JDK-8178798 Two compiler/aot/verification/vmflags tests fail by timeout with UseAVX=3 JDK-8218546 Unable to connect to https://google.com using java.net.HttpClient JDK-8214750 Unnecessary

tags in jfr classes JDK-8218465 Update name and links for JLS and JVMS JDK-8059773 Update PKCS#11 Reference Guide to add support for Mac OSX JDK-8214532 Update RFC 2459 references in javadoc to RFC 5280 JDK-8214935 Upgrade IANA LSR data JDK-8215281 Use String.isEmpty() when applicable in java.base JDK-8214568 Use {@systemProperty} for definitions of system properties JDK-8218178 vmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java fails with -Xcomp JDK-8215206 VtableStubs::find_stub is not appropriately protected by VtableStubs_lock JDK-8215400 Warn on usage of trampolines with gcc JDK-8214751 X86: Support for VNNI Instructions JDK-8215354 x86_32 build failures after JDK-8214074 (Ghash optimization using AVX instructions) JDK-8215353 x86_32 build failures after JDK-8214751 (X86: Support for VNNI Instructions) JDK-8215708 ZGC: Add missing LoadBarrierNode::size_of() JDK-8217717 ZGC: Broken oop map in C1 load barrier stub JDK-8216385 ZGC: Fix building without C2 JDK-8215547 ZGC: Fix incorrect match rule for loadBarrierWeakSlowRegNoVec JDK-8217309 ZGC: Fix ZNMethodTable corruption JDK-8215754 ZGC: nmethod is not unlinked from Method before rendezvous handshake JDK-8215755 ZGC: split_barrier_thru_phi: check number of inputs of phi JDK-8215487 ZGC: ZRuntimeWorkers incorrectly identify themselves as ZWorkers Hint: Prefix bug IDs with https://bugs.openjdk.java.net/browse/ to reach the relevant JIRA entry. JAVA ENHANCEMENT PROPOSALS (JEP): JEP 350: Dynamic CDS Archives Extend [application class-data sharing](https://openjdk.java.net/jeps/310) to allow the dynamic archiving of classes at the end of Java application execution. The archived classes will include all loaded application classes and library classes that are not present in the default, base-layer CDS archive. JEP 351: ZGC: Uncommit Unused Memory (Experimental) Enhance ZGC to return unused heap memory to the operating system. JEP 353: Reimplement the Legacy Socket API Replace the underlying implementation used by the `java.net.Socket` and `java.net.ServerSocket` APIs with a simpler and more modern implementation that is easy to maintain and debug. The new implementation will be easy to adapt to work with user-mode threads, a.k.a. fibers, currently being explored in [Project Loom](https://openjdk.java.net/projects/loom). JEP 354: Switch Expressions (Second Preview) Extend `switch` so it can be used as either a statement or an expression, and so that both forms can use either traditional `case ... :` labels (with fall through) or new `case ... ->` labels (with no fall through), with a further new statement for yielding a value from a `switch` expression. These changes will simplify everyday coding, and prepare the way for the use of [pattern matching (JEP 305)](https://openjdk.java.net/jeps/305) in `switch`. This is a [preview language feature](http://openjdk.java.net/jeps/12) in JDK 13. JEP 355: Text Blocks (Preview) Add _text blocks_ to the Java language. A text block is a multi-line string literal that avoids the need for most escape sequences, automatically formats the string in a predictable way, and gives the developer control over format when desired. This is a [preview language feature](http://openjdk.java.net/jeps/12) in JDK 13. RELEASE NOTES, BY COMPONENT: client-libs/2d: JDK-8218009: GraphicsEnvironment.getCenterPoint() and getMaximumWindowBounds() are Unified Across Platforms Two methods were added to the `GraphicsEnvironment` class in JDK 1.4: - `getCenterPoint()` - `getMaximumWindowBounds()` See [https://docs.oracle.com/javase/7/docs/technotes/guides/awt/1.4/AWTChanges.html#windowCentering](https://docs.oracle.com/javase/7/docs/technotes/guides/awt/1.4/AWTChanges.html#windowCentering). The page in the preceding link includes the following description: "X-Window, Xinerama All monitors share a single virtual coordinate space, as on Microsoft Windows. However, it is possible for the user to specify through X resources where windows should be centered. If these resources are set, `getCenterPoint` reflects their value. Otherwise, it returns the point at the center of the virtual coordinate space. (In practice, this will almost always be set - CDE sets it by default.)" Now, in JDK 13, the implementation of `getCenterPoint()` and `getMaximumWindowBounds()` has been unified across the platforms (Windows, Linux, Solaris, and macOS): - `getCenterPoint` returns the coordinates of the center of the primary display, for all platforms. - `getMaximumWindowBounds` returns the bounds of the primary display minus display insets, for all platforms. client-libs/java.awt: JDK-8225358: Removal of awt.toolkit System Property Historically (up to JDK 1.8), documentation for the `java.awt.Toolkit` class referred to the "awt.toolkit" system property, which was set to the name of the platform implementation subclass. The documentation of this property was removed in JDK 9 because (1) it was an internal detail not intended to be a supported interface and (2) encapsulation by the module system meant that the class could not be directly manipulated. However, the system property was not removed until now. Applications that previously read this property can still, if necessary, obtain it by instantiating the AWT Toolkit and querying the class name via that instance. JDK-8218779: Deprecated and Unsupported Swing Motif Look and Feel on macOS Swing Motif Look and Feel is unsupported on macOS in JDK 13. In the source code, Swing Motif Look and Feel is deprecated with the intent to remove it in a future release. Use `javax.swing.plaf.metal.MetalLookAndFeel` instead. client-libs/javax.swing: JDK-8219012: GTK+ 3.20 and Later Unsupported by Swing Due to incompatible changes in the GTK+ 3 library versions 3.20 and later, the Swing GTK Look and Feel does not render some UI components when using this library. Therefore Linux installations with versions of GTK+ 3.20 and above are not supported for use by the Swing GTK Look And Feel in this release. Affected applications on such configurations should specify the system property `-Djdk.gtk.version=2.2` to request GTK2+ based rendering instead. JDK-8219012: GTK+ 3.20 and Later Unsupported by Swing Due to incompatible changes in the GTK+ 3 library versions 3.20 and later, the Swing GTK Look and Feel does not render some UI components when using this library. Therefore Linux installations with versions of GTK+ 3.20 and above are not supported for use by the Swing GTK Look And Feel in this release. Affected applications on such configurations should specify the system property `-Djdk.gtk.version=2.2` to request GTK2+ based rendering instead. JDK-8219012: GTK+ 3.20 and Later Unsupported by Swing Due to incompatible changes in the GTK+ 3 library versions 3.20 and later, the Swing GTK Look and Feel does not render some UI components when using this library. Therefore Linux installations with versions of GTK+ 3.20 and above are not supported for use by the Swing GTK Look And Feel in this release. Affected applications on such configurations should specify the system property `-Djdk.gtk.version=2.2` to request GTK2+ based rendering instead. JDK-8219012: GTK+ 3.20 and Later Unsupported by Swing Due to incompatible changes in the GTK+ 3 library versions 3.20 and later, the Swing GTK Look and Feel does not render some UI components when using this library. Therefore Linux installations with versions of GTK+ 3.20 and above are not supported for use by the Swing GTK Look And Feel in this release. Affected applications on such configurations should specify the system property `-Djdk.gtk.version=2.2` to request GTK2+ based rendering instead. JDK-8219071: GTK+ 3.20 and Later Unsupported by Swing Due to incompatible changes in the GTK+ 3 library versions 3.20 and later, the Swing GTK Look and Feel does not render some UI components when using this library. Therefore Linux installations with versions of GTK+ 3.20 and above are not supported for use by the Swing GTK Look And Feel in this release. Affected applications on such configurations should specify the system property -Djdk.gtk.version=2.2 to request GTK2+ based rendering instead. JDK-8219072: GTK+ 3.20 and Later Unsupported by Swing Due to incompatible changes in the GTK+ 3 library versions 3.20 and later, the Swing GTK Look and Feel does not render some UI components when using this library. Therefore Linux installations with versions of GTK+ 3.20 and above are not supported for use by the Swing GTK Look And Feel in this release. JDK-8219012: GTK+ 3.20 and Later Unsupported by Swing Due to incompatible changes in the GTK+ 3 library versions 3.20 and later, the Swing GTK Look and Feel does not render some UI components when using this library. Therefore Linux installations with versions of GTK+ 3.20 and above are not supported for use by the Swing GTK Look And Feel in this release. Affected applications on such configurations should specify the system property `-Djdk.gtk.version=2.2` to request GTK2+ based rendering instead. core-libs: JDK-8224253: Improved Handling of the "Class-Path" JAR Manifest Attribute The JAR file specification has been updated to clarify what constitutes a valid entry for the `Class-Path` JAR Manifest Attribute. See the JAR file specification for further details. Invalid entries are now ignored. Applications relying on invalid `Class-Path` entries may see a `ClassNotFoundException`. A system property has been added to aid in debugging the `Class-Path` attribute. When the `"jdk.net.URLClassPath.showIgnoredClassPathEntries"` property is set to `true`, invalid `Class-Path` entries will be printed to the console. core-libs/java.lang: JDK-8218924: Default Process launch mechanism on Linux now uses posix_spawn `Runtime.exec()` and `ProcessBuilder`, on Linux now use `posix_spawn(3)` to spawn child processes. This increases reliability and performance in low-memory situations. JDK-8228689: Removal of Runtime Trace Methods The obsolete methods `traceInstructions(boolean)` and `traceMethodCalls(boolean)` have been removed from the `java.lang.Runtime` class. These methods have been non-functional for many releases, and their intended functions are provided by the Java Virtual Machine Tool Interface (JVMTI). JDK-8223588: Support for Unicode 12.1 This release upgrades Unicode support to 12.1 which includes the following: - `java.lang.Character` supports Unicode Character Database of 12.1 level, in which 12.0 adds 554 characters since 11.0, for a total of 137,928 characters. These additions include 4 new scripts, for a total of 150 scripts, as well as 61 new emoji characters. 12.1 adds exactly one character, `U+32FF SQUARE ERA NAME REIWA`, since 12.0. - `java.text.Bidi` and `java.text.Normalizer` classes support 12.0 level of Unicode Standard Annexes, #9 and #15, respectively. - `java.util.regex` package supports Extended Grapheme Clusters based on 12.0 level of Unicode Standard Annex #29 JDK-8218884: StringBuffer(CharSequence) and StringBuilder(CharSequence) Throw NegativeArraySizeException for Negatively Sized Argument The behavior of `StringBuffer(CharSequence)` and `StringBuilder(CharSequence)` is changed for the argument reporting a negative length. The constructors were inconsistently throwing either `NegativeArraySizeException` or `IndexOutOfBoundException`. The new behavior is to always throw `NegativeArraySizeException` for any argument reporting a negative length. core-libs/java.lang.invoke: JDK-8221613: Lookup.unreflectSetter(Field) Now Throws IllegalAccessException for Static Final Fields `java.lang.invoke.MethodHandles.Lookup::unreflectSetter` returns a `MethodHandle` giving write access to the given `Field` object. A `Field` object for a static final field does not have write access even if its accessible flag is true (i.e. `Field.setAccessibe(true)` has been called). In JDK 13, `Lookup::unreflectSetter` is fixed to throw `IllegalAccessException` if the given `Field` object is a static final field. core-libs/java.net: JDK-8226239: Pre-JDK 1.4 SocketImpl Implementations No Longer Supported Support for custom `java.net.SocketImpl` implementations compiled for Java SE 1.3 and older has been removed in this release. This change has no impact on `SocketImpl` implementations compiled for Java SE 1.4 (released in 2002) or newer. JDK-8226643: Change to Default Implementation of SocketImpl Methods supportedOptions, getOption, and setOption The default implementation of the `supportedOptions()`, `getOption(SocketOption)` and `setOption(SocketOption, T)` methods, defined by `java.net.SocketImpl` and `java.net.DatagramSocketImpl`, have changed in this release. The default implementation of the `supportedOptions()` method has been changed to return an empty set. The default implementations of the `getOption(SocketOption)` and `setOption(SocketOption, T)` methods have been changed to throw `UnsupportedOperationException`. Developers extending `java.net.SocketImpl` or `java.net.DatagramSocketImpl` to create their own socket or datagram socket implementations need to override these methods to support the socket options that the custom socket implementation supports. JDK-8225154: Change to ServerSocket.accept() When the System-Wide Factory for Client or Server Socket Implementations Is Set Developers using the `java.net.Socket.setSocketImplFactory` or `java.net.ServerSocket.setSocketFactory` APIs to change the system-wide factories for client socket or server socket implementations should note the following changes: 1. Invoking `ServerSocket::accept` on a `ServerSocket` using a system-default `SocketImpl` to accept a connection will always return a `Socket` with a system-default `SocketImpl`. In this case, the system-wide factory for client socket implementations will not be invoked to create the client socket implementation. 2. `java.net.ServerSocket::implAccept` has been changed to disallow a `ServerSocket` using a system-default `SocketImpl` from accepting a connection with a `Socket` using a custom `SocketImpl`. It has also been changed to disallow a `ServerSocket` using a custom `SocketImpl` to accept a connection with a `Socket` using a system-default `SocketImpl`. Disallowing these nonsensical combinations of `SocketImpl` improves reliability in cases where an application sets one, but not both, socket implementation factories. The changes should have no impact on applications that set the same factory for both client and server socket implementations. JDK-8223354: JEP 353: Reimplement the Legacy Socket API The underlying implementation for the `java.net.Socket` and `java.net.ServerSocket` APIs has been replaced in this release. JEP 353 provides all the details on this change. Every effort has been made to ensure that the new implementation is compatible with the old implementation but it is possible that there is existing code that depends on unspecified behavior in corner cases where the old and new implementations behave differently. The JDK continues to include the old implementation (known as "PlainSocketImpl" or the "plain" implementation) to allow such code continue to run. The old implementation is selected by running with the system property "`jdk.net.usePlainSockteImpl`" set, or set to the value "`true`", i.e. run with `-Djdk.net.usePlainSocketImpl` or `-Djdk.net.usePlainSocketImpl=true`. The property can also be configured in the JDK network configuration file, located in `${java.home}/conf/net.properties`. The old implementation, and the system property to select the old implementation, will be removed in a future release. core-libs/java.nio: JDK-8226802: New java.nio.ByteBuffer Bulk get/put Methods Transfer Bytes Without Regard to Buffer Position `java.nio.ByteBuffer` and the other buffer types in `java.nio` now define absolute bulk `get` and `put` methods to transfer contiguous sequences of bytes without regard to or effect on the buffer position. JDK-8225152: JNI NewDirectByteBuffer Creates Direct Buffer That Is java.nio.ByteOrder.BIG_ENDIAN The Java Native Interface (JNI) specification has been clarified in this release to specify that the `NewDirectByteBuffer` function creates a direct buffer that is always big-endian (high byte first; `java.nio.ByteOrder.BIG_ENDIAN`). This aligns the specification with long standing behavior (JDK 1.4, released in 2002) so it does not affect existing code. JDK-8223197: Added FileSystems.newFileSystem(Path, Map<String, ?>) Method Three new methods have been added to `java.nio.file.FileSystems` to make it easier to use file system providers that treat the contents of a file as a file system. - `newFileSystem(Path)` - `newFileSystem(Path, Map)` - `newFileSystem(Path, Map, ClassLoader)` The addition of `newFileSystem(Path, Map)` creates a source (but not binary) compatibility issue for code that has been using the existing 2-arg `newFileSystem(Path, ClassLoader)` and specifying the class loader as `null.` For example, the following cannot be compiled because the reference to `newFileSystem` is ambiguous: `FileSystem fs = FileSystems.newFileSystem(path, null);` To avoid the ambiguous reference, this code needs to be modified to cast the second parameter to `java.lang.ClassLoader`. JDK-8226801: Files.createSymbolicLink Can Be Used in "Developer Mode" Without Additional Privileges On Microsoft Windows, `java.nio.file.Files.createSymbolicLink` has been changed so that it can now be used to create symbolic links when the process is not elevated but the user is running in "Developer Mode". This may be useful for tools and other development time tasks that need to create symbolic links without requiring additional privileges. JDK-8225153: Files.isHidden Returns true for Hidden Directories on Windows On Microsoft Windows, the `java.nio.file.Files.isHidden` method has historically ignored the DOS "hidden" attribute on directories. This has been fixed in this release so that `isHidden` now returns `true` when invoked to test a directory that has this attribute set. core-libs/java.nio.charsets: JDK-8216588: Corrected UnicodeDecoder U+FFFE Handling The behavior of decoding the code point `U+FFFE` in the middle of the buffer has been corrected for `StandardCharsets.UTF_16[LE/BE]`. The decoders have been reporting the code point as "malformed". They now pass through the code point in order to conform to the [Unicode Consortium's Corrigendum#9](http://www.unicode.org/versions/corrigendum9.html). core-libs/java.rmi: JDK-8225318: Deprecated rmic Tool for Removal The _rmic_ tool has been deprecated and may be removed from a future release. The _rmic_ tool was used to create static stubs that support the Java Remote Method Protocol (JRMP) used by the Java Remote Method Invocation (RMI) facility. Statically generated stubs are obsolete and were replaced by dynamically generated stubs in Java SE 5.0. Dynamically generated stubs no longer require pregeneration using a tool such as _rmic_, and they are functionally equivalent to statically generated stubs. RMI applications should be migrated to use dynamically generated RMI stubs by changing the way remote objects are exported. See the class documentation for `java.rmi.server.UnicastRemoteObject` for further details. core-libs/java.time: JDK-8225062: DateTimeFormatter now throws DateTimeParseException on Invalid HOUR_OF_AMPM The parsing behavior of `DateTimeFormatter` with `HOUR_OF_AMPM` has changed. It now correctly throws a `DateTimeParseException` with an out-of-bounds input values, such as `12`. core-libs/java.util: JDK-8217706: Base64.Encoder and Base64.Decoder Methods Can Throw OutOfMemoryError The behavior of `Base64.Encoder.encode` and `Base64.Decoder.decode` methods have been changed for large arrays. The methods previously threw an unspecified exception, such as, `NegativeArraySizeException`. The new behavior throws an `OutOfMemoryError` exception if the `encode` and `decode` methods fail to allocate the output array/buffer or memory. JDK-8226735: Properties Files Containing Malformed Unicode Was Sometimes Misparsed An `IllegalArgumentException` is always thrown now when loading a properties file with malformed unicode sequences. Previously, a malformed unicode sequence appearing at the end of a line was parsed using the contents of the preceding line, which in rare cases meant it could be parsed as a valid (but likely incorrect) sequence. core-libs/java.util.logging: JDK-8219540: NullPointerException in java.util.logging.Handler#isLoggable The default implementation of `java.util.logging.Handler.isLoggable` has been updated to match its specification and to return `false` if the `record` parameter is `null`. The implementation of `java.util.logging.MemoryHandler.isLoggable` and `java.util.logging.MemoryHandler.publish` will no longer throw `NullPointerException` if the `record` parameter is `null`, which conforms to their specification. core-libs/java.util:i18n: JDK-8218762: New Japanese Era Name: Reiwa An instance representing the new Reiwa era has been added to this update. Unlike other eras, there is no public field for this era. It can be obtained by calling `JapaneseEra.of(3)` or `JapaneseEra.valueOf("Reiwa")`. JDK 13 and later will have a new public field to represent this era. The placeholder name, "`NewEra`", for the Japanese era that started from May 1st, 2019 has been replaced with the new official name. Applications that relied on the placeholder name (see JDK-8202088) to obtain the new era singleton (`JapaneseEra.valueOf("NewEra")`) will no longer work. JDK-8223587: Upgraded CLDR to Version 35.1 Locale data based on Unicode Consortium's CLDR has been upgraded to their version 35.1, which includes several localized display names for the Japanese new era, Reiwa. There are some notable locale data changes, such as year formatting in Dutch locale (JDK-8225240) and French grouping separator change (JDK-8225245). For the detailed locale data changes, please refer to the cumulative CLDR changes from the previously supported version v.33. The following are links to each CLDR upgrade release: - CLDR 33.1: http://cldr.unicode.org/index/downloads/cldr-33-1 - CLDR 34: http://cldr.unicode.org/index/downloads/cldr-34 - CLDR 35, 35.1: http://cldr.unicode.org/index/downloads/cldr-35 hotspot/compiler: JDK-8226473: More Registers Available When Running Without Compressed References on x86_64 When running with compressed references on x86_64, one of the CPU registers holds the heap base pointer to be used for references encoding/decoding. This register is not available for register allocation. Simple implementations before this release made this register unavailable (and thus unused) even if compressed references were disabled. In this release, the implementation was revised to put this unused register back into the available registers pool. Configurations with large heaps and/or `-XX:-UseCompressedOops` benefit from this improvement. hotspot/gc: JDK-8222487: Added -XX:SoftMaxHeapSize Flag The manageable command-line flag `-XX:SoftMaxHeapSize=` has been added. Currently, it only has an effect when the Z garbage collector is enabled (`-XX:+UseZGC`). When set, the GC will strive to not grow the heap beyond the specified size, unless the GC decides it's necessary to do so to avoid OutOfMemoryError. The soft max heap size is not allowed to be set to a value greater than the maximum heap size (`-Xmx`). When not set on the command line, it defaults to a value equal to the maximum heap size. Being `manageable`, its value can be adjusted at runtime. For example, its value can be adjusted by using `jcmd VM.set_flag SoftMaxHeapSize ` or through the HotSpot MXBean. Setting this flag can be useful in a number of situations, such as: * In environments where resource usage is a concern, you might want to keep the heap footprint down while also retaining the capability to deal with a temporary increase in heap space requirement. * When using a concurrent GC (such as ZGC), you might want to play it safe and increase the confidence level that you will not run into an allocation stall because of an unforeseen increase in allocation rate. Setting a soft max heap size encourages the GC to maintain a smaller heap, which means the GC will collect garbage more aggressively than it otherwise would, making it more resilient to a sudden increase in the application allocation rate. JDK-8226477: Epsilon GC Caused Excess Metaspace Resizing Safepoints In this release, Epsilon has been changed to accept GC requests and resize the metaspace to reduce the number of safepoints that are taken. Before this release, the Epsilon GC was intended to provide minimal runtime overhead by not doing GC and by ignoring all incoming GC requests. However, when a metadata-heavy workload (for example, a workload having lots of classes) needed to resize the metaspace, it relied on the GC to resize the metadata at a GC safepoint. Shared GC code would enter the safepoint to call into GC for it. However, because Epsilon ignored the GC request, the safepoint would be generated, but it would not resize the metaspace. This would cause another safepoint to be generated soon afterwards without ever resizing the metaspace. JDK-8226478: JFR events for Shenandoah This release implements two JFR events ShenandoahHeapRegionStateChange and ShenandoahHeapRegionInformation which provide internal GC diagnostic data that can be used to visualize the shenandoah heap regions. JDK-8225343: Improve Ergonomics for Sparse PRT Entry Size This enhancement changes the ergonomics for sizing the lowest level (most quickly to access, but taking most space per element) remembered set memory storage in G1 called Sparse PRTs. The number of entries now grow exponentially with region size instead of linearly. This means that G1 uses 4/8/16/32/62/128 entries per Sparse PRT if configured for 1/2/4/8/16/32 MB regions respectively instead of 4/8/12/16/20/24 entries. With this change, G1 uses significantly less memory for remembered sets for applications requiring a significant amount of remembered sets. This may also result in decreased garbage collection pause times in these cases. The ergonomically determined values may be overridden using the `-XX:G1RSetSparseRegionEntries` option as before. JDK-8226901: Improve the Behavior of MaxRAM Settings and UseCompressedOops The behavior of several GC Heap selection flags have been changed to better meet the expectation of users. Prior to this change, if the heap size selection resulting from the use of these flags exceeded the maximum reachable address when `UseCompressedOops` is enabled, the heap size would be truncated to be within the `CompressedOops` range. Also, the percentage or fractional calculation performed was based on the value of `MaxRAM` and not the amount of physical memory available in the system. The following are the options impacted by this change: - `-XX:MaxRAMPercentage` - `-XX:MaxRAMFraction` - `-XX:MinRAMPercentage` - `-XX:MinRAMFraction` - `-XX:InitialRAMPercentage` - `-XX:InitialRAMFraction` - `-XX:MaxRAM` The new behavior calculates the percentage or fraction based on the host's available memory unless the user also specifies `-XX:MaxRAM`. In addition, `UseCompressedOops` is automatically disabled if the heap size resulting from the use of any of these options, including `-XX:MaxRAM`, is greater than can be addressed in `CompressedOops` mode, unless the `-XX:+UseCompressedOops` option is specified to override this behavior. Note: This change only impacts 64-bit platforms. JDK-8222481: JEP 351: ZGC: Uncommit Unused Memory ZGC was enhanced to return unused heap memory to the operating system. This is useful for applications and environments where memory footprint is a concern. This feature is enabled by default, but can be explicitly disabled using `-XX:-ZUncommit`. Furthermore, memory will not be uncommitted so that the heap size shrinks below the minimum heap size (`-Xms`). This means this feature will be implicitly disabled if the minimum heap size (`-Xms`) is configured to be equal to the maximum heap size (`-Xmx`). An uncommit delay can be configured using `-XX:ZUncommitDelay=` (defaults to 300 seconds). This delay specifies for how long memory should have been unused before it's eligible for uncommit. For more details, see ([JEP 351](http://openjdk.java.net/jeps/351)). JDK-8225516: Load reference barriers for Shenandoah Shenandoah used to employ the weak to-space invariant: allow reads to be done from the collection set while it is being evacuated, and evacuate objects on writes to them. This forced the implementation to have simple read barriers before every read accesses (including primitive ones), and complicated write barriers before every write access (including primitive ones), plus handling the cases where both copies of the objects are exposed (for example, in acmp). With this change, Shenandoah rewires the barriers to employ stronger to-space invariant: never expose objects in the collection set, evacuating them eagerly on reference load. Implementation rewires that used to be the write barrier handling code to every reference load, and removes other barriers (read, acmp, storeval barriers). The change makes simpler barrier interface, provides more opportunities for performance optimizations, reduces the maintenance burden. Even though Shenandoah makes more complicated read barriers with this change, the incidence of those barriers is lower, because there are no barriers on writes anymore, and only reference loads need to be handled. This makes the change performance neutral or performance-positive on many workloads, even with simpler optimization code. JDK-8226475: Improvements in Serial GC Young pause time report With Serial GC, when Young GC fails and upgrades to Full GC, the logging messages may be confusing. In previous releases, the log would say both "Pause Full" and "Pause Young" finished at the same time, leading to double-counting the pause time. In this release, the logging is fixed to properly reflect times spent in "Young" and "Full" collections. See more at JDK-8215221. JDK-8225523: Shenandoah Support for Solaris x86_64 Shenandoah is designed to be OS agnostic. However, minor differences in accepted language features in OS-specific tool chains can prevent it from being buildable on some operating systems. This release includes a change that enables Shenandoah builds with Solaris Studio, the default tool chain for the Solaris operating system. Testing shows that, after this change is applied, Shenandoah is fully operational on Solaris 11. JDK-8226483: Shenandoah Accepts Arbitrarily Low Initial Heap Size The Shenandoah implementation has been improved to allow arbitrarily low initial heap size. Before this change, Shenandoah needed at least 10 regions to cover `-Xms`. With large heaps and/or larger regions, those 10 regions could use a significant amount of space. This requirement is relaxed now, and Shenandoah can run with the lowest `-Xms` that the shared JVM code can accept. JDK-8225524: Shenandoah Changes -Xms to Mean "minimum heap size" Before the changes in this release, `-Xms` was treated as setting the "initial heap size." This enabled the Shenandoah heap sizing policy to uncommit unused heap that was below that setting. With this release, `-Xms` is treated as providing the "minimum heap size." This change prevents Shenandoah from uncommitting unused heap that is below the `-Xms` setting. `-Xms` can now be used to fine-tune footprint vs. allocation overhead tradeoffs. JDK-8226482: Shenandoah Logs Report Proper Committed Heap Size In previous releases, Shenandoah reported the max heap size as the current heap size. This reporting error resulted from changing the heap sizing scheme to per-region commit/uncommit. In this release, Shenandoah reports the proper amount of committed memory that is taken by the current heap. The changes in this release also eliminate redundant logging lines that print reserved/committed/used memory sizes. This change makes Shenandoah GC logging more consistent with other GCs. Users are advised to check their GC log parsing scripts. See JDK-8222185. JDK-8225531: Shenandoah x86_32 support Shenandoah now experimentally supports x86_32 in fully concurrent mode. This allows memory footprint improvements in VM-heavy workloads, when most of the memory taken by JVM are VM-native structures. This also serves as the proof Shenandoah is implementable on 32-bit platforms. JDK-8225530: Shenandoah eliminated separate forwarding pointer slot Shenandoah uses an extra word per object to store the forwarding pointer of an object in support of concurrent evacuation. With the arrival of load reference barriers, it is possible to store the forwarding pointer in the then-unused memory of old copy of an object instead, for example use the old copy mark-word and encode the forwarding pointer there. This allows to eliminate the extra forwarding pointer word, and thus reduces memory footprint to that of regular GC. JDK-8226476: Shenandoah reduces the default number of GC threads In previous releases, Shenandoah GC defaulted to the large number of concurrent and parallel GC threads to do the work. In many cases, this lead to taking a significant CPU toll when GC was running. In worst case, the system can be saturated with the GC work alone. In this release, the default number of concurrent and parallel Shenandoah GC threads is trimmed down to 1/4 and 1/2 of CPU threads, respectively. Users are advised to check if their installations benefit from these new defaults, or adjust `-XX:ConcGCThreads=#` or `-XX:ParallelGCThreads=#` if needed. JDK-8222920: ZGC: Maximum Heap Size Increased to 16TB The maximum supported heap size for ZGC was increased from 4TB to 16TB. hotspot/runtime: JDK-8230630: Deprecated Java Options -Xverify:none and -noverify The Java options `-Xverify:none` and `-noverify` have been deprecated in this release. The options will continue to work as intended but will generate the following warning when used: warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be removed in a future release. Deprecating these options helps prevent users from running code that violates the JVM Specification, which can leave their applications open to malicious code. Users who need to run without startup verification can use AppCDS to archive their classes. The classes are verified during archiving and avoid verification at runtime. Note that if you encounter issues while using either of these options, it is very likely that you will be required to reproduce the problem without using these options before Oracle Support can assist with an investigation. JDK-8218003: Deprecated Java Options -Xverify:none and -noverify The Java options `-Xverify:none` and `-noverify` have been deprecated in this release. The options will continue to work as intended but will generate the following warning when used: warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be removed in a future release. Deprecating these options helps prevent users from running code that violates the JVM Specification, which can leave their applications open to malicious code. Users who need to run without startup verification can use AppCDS to archive their classes. The classes are verified during archiving and avoid verification at runtime. JDK-8226529: JEP 350 Dynamic CDS Archiving JEP 350 extends application class-data sharing ([AppCDS](https://openjdk.java.net/jeps/310)) to allow the dynamic archiving of classes as a Java application is exiting. It also improves the usability of AppCDS by eliminating the need for users to do trial runs to create a class list for each application. The existing static archiving enabled by the `-Xshare:dump` option, using a class list, continues work as is. The dynamically-generated archive is created on top of the default system archive packaged with the running JDK image. A separate top-layer archive file is generated for each application. The user can specify the filename of the dynamic archive name as the argument to the `-XX:ArchiveClassesAtExit` option. For example, the following command creates `hello.jsa`: ``` % bin/java -XX:ArchiveClassesAtExit=hello.jsa -cp hello.jar Hello ``` To run the same application using this dynamic archive: ``` % bin/java -XX:SharedArchiveFile=hello.jsa -cp hello.jar Hello ``` The user could also specify both the base and the dynamic archives in the `-XX:SharedArchiveFile` option such as: ``` -XX:SharedArchiveFile=: ``` [CSR JDK-8221706](https://bugs.openjdk.java.net/browse/JDK-8221706) has more details on the command line option. JDK-8216320: Removal of VM option -XX:+AggressiveOpts The VM option `-XX:+AggressiveOpts` was deprecated in JDK 11 and support for it was removed in JDK 12 (where its use was ignored other than generating a warning). Use of this flag will now cause an error on VM initialization. security-libs/java.security: JDK-8221983: New keytool -showinfo -tls Command for Displaying TLS Configuration Information A new `keytool -showinfo -tls` command has been added that displays TLS configuration information. JDK-8225688: Support for MS Cryptography Next Generation (CNG) The SunMSCAPI provider now supports reading private keys in Cryptography Next Generation (CNG) format. This means that RSA and EC keys in CNG format are loadable from Windows keystores, such as "Windows-MY". Signature algorithms related to EC (`SHA1withECDSA`, `SHA256withECDSA`, etc.) are also supported. JDK-8223648: Configurable Read Timeout for CRLs The `com.sun.security.crl.readtimeout` system property sets the maximum read timeout for CRL retrievals, in seconds. If the property has not been set, or if its value is negative, it is set to the default value of 15 seconds. A value of 0 means an infinite timeout. JDK-8223161: Removal of T-Systems Deutsche Telekom Root CA 2 Certificate The T-Systems Deutsche Telekom Root CA 2 certificate has expired and was removed from the `cacerts` keystore: + alias name "deutschetelekomrootca2 [jdk]" Distinguished Name: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche Telekom AG, C=DE JDK-8223976: Removal of Two Comodo Root CA Certificates Two Comodo root CA certificates have expired and were removed from the `cacerts` keystore: + alias name "utnuserfirstclientauthemailca [jdk]" Distinguished Name: CN=UTN-USERFirst-Client Authentication and Email, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US + alias name "utnuserfirsthardwareca [jdk]" Distinguished Name: CN=UTN-USERFirst-Hardware, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US JDK-8224004: Removal of Two DocuSign Root CA Certificates Two DocuSign root CA certificates have expired and were removed from the `cacerts` keystore: + alias name "certplusclass2primaryca [jdk]" Distinguished Name: CN=Class 2 Primary CA, O=Certplus, C=FR + alias name "certplusclass3pprimaryca [jdk]" Distinguished Name: CN=Class 3P Primary CA, O=Certplus, C=FR security-libs/javax.crypto: JDK-8220791: Use SunJCE Mac in SecretKeyFactory PBKDF2 Implementation The SunJCE implementation of the PBKDF2 SecretKeyFactory will now exclusively use the SunJCE Mac service for the underlying pseudorandom function (PRF). This fixes an issue where 3rd party JCE providers in rare cases could cause the SunJCE PBKDF2 SecretKeyFactory's underlying pseudorandom function (PRF) to fail on `Mac.init()`. security-libs/javax.crypto:pkcs11: JDK-8215018: Memory Growth Issue in SunPKCS11 Fixed A memory growth issue in the SunPKCS11 cryptographic provider that affects the NSS back-end has been fixed. A system property, `sun.security.pkcs11.disableKeyExtraction` has been introduced to disable the fix. A "`true`" value disables the fix, while a "`false`" value (default) keeps it enabled. When enabled, PKCS#11 attributes of the NSS native keys are copied to Java byte buffers after key creation. Once used, NSS keys are destroyed and native heap space is freed up. If NSS keys are required again, they are recreated with the previously saved attributes. Further information and implementation details can be found in the CSR: JDK-8213430 JDK-8221441: SunPKCS11 Provider Upgraded with Support for PKCS#11 v2.40 The SunPKCS11 provider has been updated with support for PKCS#11 v2.40. This version adds support for more algorithms such as the AES/GCM/NoPadding cipher, DSA signatures using SHA-2 family of message digests, and RSASSA-PSS signatures when the corresponding PKCS11 mechanisms are supported by the underlying PKCS11 library. security-libs/javax.net.ssl: JDK-8220615: Duplicated RSA Services No Longer Supported by SunJSSE Provider Support for `RSA KeyFactory`, `RSA KeyPairGenerator`, `MD2withRSA`, `MD5withRSA`, and `SHA1withRSA Signature` has been removed from SunJSSE provider. Since JDK 5, `SunRsaSign` provider was introduced to support these RSA-related algorithms. The only reason for SunJSSE provider to support these was for backward-compatibility with pre-JDK 5 applications. Removal should only impact applications that explicitly request these RSA services from SunJSSE provider. Applications should remove the hardcoded "SunJSSE" provider name. JDK-8219478: Deprecated javax.security.cert APIs with forRemoval=true The `javax.security.cert` API has been deprecated and marked for removal. The classes in this package should no longer be used. The `java.security.cert` package contains suitable replacements. JDK-8217911: Removal of Experimental FIPS 140 Compliant Mode from SunJSSE Provider The experimental FIPS 140 compliant mode has been removed from the SunJSSE provider. Legacy applications might have used the experimental mode with one of the following approaches: 1. Updating the `java.security` file and specifying a crypto provider for the SunJSSE provider (for example, `security.provider.4=com.sun.net.ssl.internal.ssl.Provider SunPKCS11-NSS`) 2. Using the JDK internal class and creating a provider with a specified crypto provider (for example, `new com.sun.net.ssl.internal.ssl.Provider(cryptoProvider);`). Because the SunJSSE provider uses JDK default cryptography providers, applications can configure the `security.provider` security properties to use the FIPS 140 compliant cryptography providers. JDK-8219479: Removal of the Internal com.sun.net.ssl package which was only used for Compatibility with Legacy JSSE 1.0 Applications The internal package `com.sun.net.ssl` has been removed from the JDK. Prior to Java SE 1.4, when JSSE was shipped as a standalone product, the `com.sun.net.ssl` APIs were supported, but since Java SE 1.4, the package was deprecated and intended for internal use only. Standard replacement APIs such as `HostNameVerifier`, `KeyManager`, and `TrustManager` have been available in the `javax.net.ssl` package since Java SE 1.4. Although applications should have transitioned to the standard APIs, this note is a final warning that these non-standard APIs have been removed. JDK-8227105: Session Resumption without Server-Side State in JSSE The feature allows for the server-side of JSSE to operate stateless. As described in RFC 5077[1] for TLS 1.2 and below, and RFC 8446[2] for TLS 1.3, the TLS server sends internal session information in the form of an encrypted session ticket to a client that supports stateless. That session ticket is presented to the server during the TLS handshake to resume the session. This should improve the performance and memory usage of the TLS server under large workloads as the session cache will seldom be used. With less session information cached, some session information may not be available. This feature is not enabled by default and can be turned on by setting two properties. Note that invalidated stateless TLS sessions could be resumed in the current implementation. The behavior is not guaranteed to be the same in future releases and updates (see bugid JDK-8229148) Note that in the current implementation, the return value of `SSLSession.getID()` is not persistent across resumption for TLS 1.3 and stateless TLS 1.2 connections. This could be an issue if applications rely on the session identifier values. This may change to be consistent a future release (See bugid JDK-8229149) Two new System properties are added in support of this feature: `jdk.tls.client.enableSessionTicketExtension` is used on the client side to toggle the Session Ticket Extension on the ClientHello message for TLS 1.2. Property value: "`true`" sends the extension, "`false`" does not (default). `jdk.tls.server.enableSessionTicketExtension` enables a server to use stateless session tickets if the client supports it. Clients that do not support stateless session tickets will use the cache. Property value: "`true`" enables stateless, "`false`" does not (default). [1]: https://tools.ietf.org/html/rfc5077 [2]: https://tools.ietf.org/html/rfc8446 JDK-8225764: Support for X25519 and X448 in TLS The named elliptic curve groups `x25519` and `x448` are now available for JSSE key agreement in TLS versions 1.0 to 1.3, with `x25519` being the most preferred of the default enabled named groups. The default ordered list is now: ``` x25519, secp256r1, secp384r1, secp521r1, x448, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192 ``` The default list can be overridden using the system property *`jdk.tls.namedGroups`*. JDK-8219551: Updated the Default Enabled Cipher Suites Preference The preference of the default enabled cipher suites has been changed. The compatibility impact should be minimal. If needed, applications can customize the enabled cipher suites and the preference. For more details, refer to the SunJSSE provider documentation and the JSSE Reference Guide documentation. JDK-8219663: Use Server Cipher Suites Preference by Default For TLS connections, the cipher suite selection, by default, is updated to use the server cipher suites preference. Applications can configure the behavior by using the `SSLParameters.setUseCipherSuitesOrder​()` method. security-libs/javax.security: JDK-8227564: Allow SASL Mechanisms to Be Restricted A security property named `jdk.sasl.disabledMechanisms` has been added that can be used to disable SASL mechanisms. Any disabled mechanism will be ignored if it is specified in the `mechanisms` argument of `Sasl.createSaslClient` or the `mechanism` argument of `Sasl.createSaslServer`. The default value for this security property is empty, which means that no mechanisms are disabled out-of-the-box. security-libs/javax.xml.crypto: JDK-8224943: [xmldsig] Added KeyValue::EC_TYPE The `ECKeyValue` type as described in the [W3C Recommendation for XML-Signature Syntax and Processing](https://www.w3.org/TR/xmldsig-core/#sec-ECKeyValue) is now supported. A new `EC_TYPE` constant has been added to the `javax.xml.crypto.dsig.keyinfo.KeyValue` interface. Please note that only the `NamedCurve` domain parameter type is currently supported, and the `ECParameters` explicit curve parameter type is not supported. JDK-8225051: New String Constants for Canonical XML 1.1 URIs New String constants named `INCLUSIVE_11` and `INCLUSIVE_11_WITH_COMMENTS` have been added to the `javax.xml.crypto.dsig.CanonicalizationMethod` API. These represent the URIs for the Canonical XML 1.1 and Canonical XML 1.1 with Comments algorithms for XML Signature. JDK-8230839: Updated XML Signature Implementation to Apache Santuario 2.1.3 The XML Signature implementation in the `java.xml.crypto` module has been updated to version 2.1.3 of Apache Santuario. New features include: * Added support for embedding elliptic curve public keys in the KeyValue element security-libs/org.ietf.jgss: JDK-8214079: Added a Default Native GSS-API Library on Windows A native GSS-API library has been added to JDK on the Windows platform. The library is client-side only and uses the default credentials. It will be loaded when the `sun.security.jgss.native` system property is set to "true". A user can still load a third-party native GSS-API library by setting the system property `sun.security.jgss.lib` to its path. security-libs/org.ietf.jgss:krb5: JDK-8225387: Support for Kerberos Cross-Realm Referrals (RFC 6806) The Kerberos client has been enhanced with the support of principal name canonicalization and cross-realm referrals, as defined by the RFC 6806 protocol extension. As a result of this new feature, the Kerberos client can take advantage of more dynamic environment configurations and does not necessarily need to know (in advance) how to reach the realm of a target principal (user or service). Support is enabled by default and 5 is the maximum number of referral hops allowed. To turn it off, set the `sun.security.krb5.disableReferrals` security or system property to false. To configure a custom maximum number of referral hops, set the `sun.security.krb5.maxReferrals` security or system property to any positive value. See further information in JDK-8223172. specification/language: JDK-8226915: JEP 354: Switch Expressions (Preview) Extend `switch` so it can be used as either a statement or an expression, and so that both forms can use either traditional `case ... :` labels (with fall through) or new `case ... ->` labels (with no fall through), with a further new statement for yielding a value from a `switch` expression. These changes will simplify everyday coding, and prepare the way for the use of [pattern matching](https://openjdk.java.net/jeps/8213076) in `switch`. This is a [preview language feature](http://openjdk.java.net/jeps/12) in JDK 13. JDK-8236934: JEP 378: Text Blocks Summary ------- Add _text blocks_ to the Java language. A text block is a multi-line string literal that avoids the need for most escape sequences, automatically formats the string in a predictable way, and gives the developer control over the format when desired. History ------- Text blocks were proposed by [JEP 355](https://openjdk.java.net/jeps/355) in early 2019 as a follow-on to explorations begun in [JEP 326](https://openjdk.java.net/jeps/326) (Raw String Literals), which was initially targeted to JDK 12 but eventually [withdrawn and did not appear in that release](https://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002402.html). JEP 355 was [targeted to JDK 13 in June 2019](https://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003050.html) as a [preview feature](http://openjdk.java.net/jeps/12). Feedback on JDK 13 suggested that text blocks should be previewed again in JDK 14, with the addition of [two new escape sequences](#New-escape-sequences). Consequently, [JEP 368](https://openjdk.java.net/jeps/368) was [targeted to JDK 14 in November 2019](https://mail.openjdk.java.net/pipermail/jdk-dev/2019-November/003653.html) as a preview feature. Feedback on JDK 14 suggested that text blocks were ready to become final and permanent in JDK 15 with no further changes. Goals ----- - Simplify the task of writing Java programs by making it easy to express strings that span several lines of source code, while avoiding escape sequences in common cases. - Enhance the readability of strings in Java programs that denote code written in non-Java languages. - Support migration from string literals by stipulating that any new construct can express the same set of strings as a string literal, interpret the same escape sequences, and be manipulated in the same ways as a string literal. - Add escape sequences for managing explicit white space and newline control. Non-Goals --------- - It is not a goal to define a new reference type, distinct from `java.lang.String`, for the strings expressed by any new construct. - It is not a goal to define new operators, distinct from `+`, that take `String` operands. - Text blocks do not directly support string interpolation. Interpolation may be considered in a future JEP. In the meantime, the new instance method `String::formatted` aids in situations where interpolation might be desired. - Text blocks do not support raw strings, that is, strings whose characters are not processed in any way. Motivation ---------- In Java, embedding a snippet of HTML, XML, SQL, or JSON in a string literal `"..."` usually requires significant editing with escapes and concatenation before the code containing the snippet will compile. The snippet is often difficult to read and arduous to maintain. More generally, the need to denote short, medium, and long blocks of text in a Java program is near universal, whether the text is code from other programming languages, structured text representing golden files, or messages in natural languages. On the one hand, the Java language recognizes this need by allowing strings of unbounded size and content; on the other hand, it embodies a design default that strings should be small enough to denote on a single line of a source file (surrounded by " characters), and simple enough to escape easily. This design default is at odds with the large number of Java programs where strings are too long to fit comfortably on a single line. Accordingly, it would improve both the readability and the writability of a broad class of Java programs to have a linguistic mechanism for denoting strings more literally than a string literal -- across multiple lines and without the visual clutter of escapes. In essence, a two-dimensional block of text, rather than a one-dimensional sequence of characters. Still, it is impossible to predict the role of every string in Java programs. Just because a string spans multiple lines of source code does not mean that newline characters are desirable in the string. One part of a program may be more readable when strings are laid out over multiple lines, but the embedded newline characters may change the behavior of another part of the program. Accordingly, it would be helpful if the developer had precise control over where newlines appear, and, as a related matter, how much white space appears to the left and right of the "block" of text. ### HTML example _Using "one-dimensional" string literals_ ``` String html = "\n" + " \n" + "

Hello, world

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

Hello, world

"""; ``` ### SQL example _Using "one-dimensional" string literals_ ``` String query = "SELECT \"EMP_ID\", \"LAST_NAME\" FROM \"EMPLOYEE_TB\"\n" + "WHERE \"CITY\" = 'INDIANAPOLIS'\n" + "ORDER BY \"EMP_ID\", \"LAST_NAME\";\n"; ``` _Using a "two-dimensional" block of text_ ``` String query = """ SELECT "EMP_ID", "LAST_NAME" FROM "EMPLOYEE_TB" WHERE "CITY" = 'INDIANAPOLIS' ORDER BY "EMP_ID", "LAST_NAME"; """; ``` ### Polyglot language example _Using "one-dimensional" string literals_ ``` ScriptEngine engine = new ScriptEngineManager().getEngineByName("js"); Object obj = engine.eval("function hello() {\n" + " print('\"Hello, world\"');\n" + "}\n" + "\n" + "hello();\n"); ``` _Using a "two-dimensional" block of text_ ``` ScriptEngine engine = new ScriptEngineManager().getEngineByName("js"); Object obj = engine.eval(""" function hello() { print('"Hello, world"'); } hello(); """); ``` Description ----------- > _This section is identical to the same section in this JEP's predecessor, [JEP 355](https://openjdk.java.net/jeps/355), except for the addition of the subsection on [new escape sequences](#New-escape-sequences)._ A _text block_ is a new kind of literal in the Java language. It may be used to denote a string anywhere that a _[string literal](https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-3.10.5)_ could appear, but offers greater expressiveness and less accidental complexity. A text block consists of zero or more content characters, enclosed by opening and closing delimiters. The _opening delimiter_ is a sequence of three double quote characters (`"""`) followed by zero or more white spaces followed by a line terminator. The _content_ begins at the first character after the line terminator of the opening delimiter. The _closing delimiter_ is a sequence of three double quote characters. The content ends at the last character before the first double quote of the closing delimiter. The content may include double quote characters directly, unlike the characters in a string literal. The use of `\"` in a text block is permitted, but not necessary or recommended. Fat delimiters (`"""`) were chosen so that `"` characters could appear unescaped, and also to visually distinguish a text block from a string literal. The content may include line terminators directly, unlike the characters in a string literal. The use of `\n` in a text block is permitted, but not necessary or recommended. For example, the text block: ``` """ line 1 line 2 line 3 """ ``` is equivalent to the string literal: ``` "line 1\nline 2\nline 3\n" ``` or a concatenation of string literals: ``` "line 1\n" + "line 2\n" + "line 3\n" ``` If a line terminator is not required at the end of the string, then the closing delimiter can be placed on the last line of content. For example, the text block: ``` """ line 1 line 2 line 3""" ``` is equivalent to the string literal: ``` "line 1\nline 2\nline 3" ``` A text block can denote the empty string, although this is not recommended because it needs two lines of source code: ``` String empty = """ """; ``` Here are some examples of ill-formed text blocks: ``` String a = """"""; // no line terminator after opening delimiter String b = """ """; // no line terminator after opening delimiter String c = """ "; // no closing delimiter (text block continues to EOF) String d = """ abc \ def """; // unescaped backslash (see below for escape processing) ``` ### Compile-time processing A text block is a [constant expression](https://docs.oracle.com/javase/specs/jls/se12/html/jls-15.html#jls-15.28) of type `String`, just like a string literal. However, unlike a string literal, the content of a text block is processed by the Java compiler in three distinct steps: 1. Line terminators in the content are translated to LF (`\u000A`). The purpose of this translation is to follow the principle of least surprise when moving Java source code across platforms. 2. Incidental white space surrounding the content, introduced to match the indentation of Java source code, is removed. 3. Escape sequences in the content are interpreted. Performing interpretation as the final step means developers can write escape sequences such as `\n` without them being modified or deleted by earlier steps. The processed content is recorded in the `class` file as a `CONSTANT_String_info` entry in the constant pool, just like the characters of a string literal. The `class` file does not record whether a `CONSTANT_String_info` entry was derived from a text block or a string literal. At run time, a text block is evaluated to an instance of `String`, just like a string literal. Instances of `String` that are derived from text blocks are indistinguishable from instances derived from string literals. Two text blocks with the same processed content will refer to the same instance of `String` due to [interning](https://docs.oracle.com/javase/specs/jvms/se12/html/jvms-5.html#jvms-5.1-300), just like for [string literals](https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-3.10.5-410). The following sections discuss compile-time processing in more detail. #### 1. Line terminators Line terminators in the content are _normalized_ from CR (`\u000D`) and CRLF (`\u000D\u000A`) to LF (`\u000A`) by the Java compiler. This ensures that the string derived from the content is equivalent across platforms, even if the source code has been translated to a platform encoding (see `javac -encoding`). For example, if Java source code that was created on a Unix platform (where the line terminator is LF) is edited on a Windows platform (where the line terminator is CRLF), then without normalization, the content would become one character longer for each line. Any algorithm that relied on LF being the line terminator might fail, and any test that needed to verify string equality with `String::equals` would fail. The escape sequences `\n` (LF), `\f` (FF), and `\r` (CR) are _not_ interpreted during normalization; escape processing happens later. #### 2. Incidental white space The text blocks [shown above](#Motivation) were easier to read than their concatenated string literal counterparts, but the obvious interpretation for the content of a text block would include the spaces added to indent the embedded string so that it lines up neatly with the opening delimiter. Here is the HTML example using dots to visualize the spaces that the developer added for indentation: ``` String html = """ .............. .............. ..............

Hello, world

.............. .............. .............."""; ``` Since the opening delimiter is generally positioned to appear on the same line as the statement or expression which consumes the text block, there is no real significance to the fact that 14 visualized spaces start each line. Including those spaces in the content would mean the text block denotes a string different from the one denoted by the concatenated string literals. This would hurt migration, and be a recurring source of surprise: it is overwhelmingly likely that the developer does _not_ want those spaces in the string. Also, the closing delimiter is generally positioned to align with the content, which further suggests that the 14 visualized spaces are insignificant. Spaces may also appear at the end of each line, especially when a text block is populated by copy-pasting snippets from other files (which may themselves have been formed by copy-pasting from yet more files). Here is the HTML example reimagined with some trailing white space, again using dots to visualize spaces: ``` String html = """ ................. .............. ..............

Hello, world

.... .............. . ................. .............."""; ``` Trailing white space is most often unintentional, idiosyncratic, and insignificant. It is overwhelmingly likely that the developer does not care about it. Trailing white space characters are similar to line terminators, in that both are invisible artifacts of the source code editing environment. With no visual guide to the presence of trailing white space characters, including them in the content would be a recurring source of surprise, as it would affect the length, hash code, etc, of the string. Accordingly, an appropriate interpretation for the content of a text block is to differentiate _incidental white space_ at the start and end of each line, from _essential white space_. The Java compiler processes the content by removing incidental white space to yield what the developer intended. `String::indent` can then be used to further manipulate indentation if desired. Using `|` to visualize margins: ``` || | | |

Hello, world

| | | || ``` The _re-indentation algorithm_ takes the content of a text block whose line terminators have been normalized to LF. It removes the same amount of white space from each line of content until at least one of the lines has a non-white space character in the leftmost position. The position of the opening `"""` characters has no effect on the algorithm, but the position of the closing `"""` characters does have an effect if placed on its own line. The algorithm is as follows: 1. Split the content of the text block at every LF, producing a list of _individual lines_. Note that any line in the content which was just an LF will become an empty line in the list of individual lines. 2. Add all _non-blank_ lines from the list of individual lines into a set of _determining lines_. (Blank lines -- lines that are empty or are composed wholly of white space -- have no visible influence on the indentation. Excluding blank lines from the set of determining lines avoids throwing off step 4 of the algorithm.) 3. If the last line in the list of individual lines (i.e., the line with the closing delimiter) is _blank_, then add it to the set of determining lines. (The indentation of the closing delimiter should influence the indentation of the content as a whole -- a [_significant trailing line_](#Significant-trailing-line-policy) policy.) 4. Compute the _common white space prefix_ of the set of determining lines, by counting the number of leading white space characters on each line and taking the minimum count. 5. Remove the common white space prefix from each _non-blank_ line in the list of individual lines. 6. Remove all trailing white space from all lines in the modified list of individual lines from step 5. This step collapses wholly-white-space lines in the modified list so that they are empty, but does not discard them. 7. Construct the result string by joining all the lines in the modified list of individual lines from step 6, using LF as the separator between lines. If the final line in the list from step 6 is empty, then the joining LF from the previous line will be the last character in the result string. The escape sequences `\b` (backspace), `\t` (tab) and `\s` (space) are _not_ interpreted by the algorithm; escape processing happens later. Similarly, the `\` escape sequence does not prevent the splitting of lines on the line-terminator since the sequence is treated as two separate characters until escape processing. The re-indentation algorithm will be normative in _The Java Language Specification_. Developers will have access to it via `String::stripIndent`, a new instance method. #### Significant trailing line policy Normally, one would format a text block in two ways: first, position the left edge of the content to appear under the first `"` of the opening delimiter, and second, place the closing delimiter on its own line to appear exactly under the opening delimiter. The resulting string will have no white space at the start of any line, and will not include the trailing blank line of the closing delimiter. However, because the trailing blank line is considered a _determining line_, moving it to the left has the effect of reducing the common white space prefix, and therefore reducing the the amount of white space that is stripped from the start of every line. In the extreme case, where the closing delimiter is moved all the way to the left, that reduces the common white space prefix to zero, effectively opting out of white space stripping. For example, with the closing delimiter moved all the way to the left, there is no incidental white space to visualize with dots: ``` String html = """

Hello, world

"""; ``` Including the trailing blank line with the closing delimiter, the common white space prefix is zero, so zero white space is removed from the start of each line. The algorithm thus produces: (using `|` to visualize the left margin) ``` | | |

Hello, world

| | ``` Alternatively, suppose the closing delimiter is not moved all the way to the left, but rather under the `t` of `html` so it is eight spaces deeper than the variable declaration: ``` String html = """

Hello, world

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

Hello, world

........ ........ ........"""; ``` Including the trailing blank line with the closing delimiter, the common white space prefix is eight, so eight white spaces are removed from the start of each line. The algorithm thus preserves the essential indentation of the content relative to the closing delimiter: ``` | | |

Hello, world

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

Hello, world

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

Hello, world

.............. .............. .............. """; ``` The common white space prefix is 14, so 14 white spaces are removed from the start of each line. The trailing blank line is stripped to leave an empty line, which being the last line is then discarded. In other words, moving the closing delimiter to the right of the content has no effect, and the algorithm again preserves the essential indentation of the content: ``` | | |

Hello, world

| | ``` #### 3. Escape sequences After the content is re-indented, any _escape sequences_ in the content are interpreted. Text blocks support all of the escape sequences supported in string literals, including `\n`, `\t`, `\'`, `\"`, and `\\`. See [section 3.10.6](https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-3.10.6) of the _The Java Language Specification_ for the full list. Developers will have access to escape processing via `String::translateEscapes`, a new instance method. Interpreting escapes as the final step allows developers to use `\n`, `\f`, and `\r` for vertical formatting of a string without it affecting the translation of line terminators in step 1, and to use `\b` and `\t` for horizontal formatting of a string without it affecting the removal of incidental white space in step 2. For example, consider this text block that contains the `\r` escape sequence (CR): ``` String html = """ \r \r

Hello, world

\r \r \r """; ``` The CR escapes are not processed until after the line terminators have been normalized to LF. Using Unicode escapes to visualize LF (`\u000A`) and CR (`\u000D`), the result is: ``` |\u000D\u000A | \u000D\u000A |

Hello, world

\u000D\u000A | \u000D\u000A |\u000D\u000A ``` Note that it is legal to use `"` freely inside a text block, even next to the opening or closing delimiter. For example: ``` String story = """ "When I use a word," Humpty Dumpty said, in rather a scornful tone, "it means just what I choose it to mean - neither more nor less." "The question is," said Alice, "whether you can make words mean so many different things." "The question is," said Humpty Dumpty, "which is to be master - that's all." """; ``` However, sequences of three `"` characters require the escaping of at least one `"` to avoid mimicking the closing delimiter: ``` String code = """ String text = \""" A text block inside a text block \"""; """; ``` ### New escape sequences To allow finer control of the processing of newlines and white space, we introduce two new escape sequences. First, the `\` escape sequence explicitly suppresses the insertion of a newline character. For example, it is common practice to split very long string literals into concatenations of smaller substrings, and then hard wrap the resulting string expression onto multiple lines: String literal = "Lorem ipsum dolor sit amet, consectetur adipiscing " + "elit, sed do eiusmod tempor incididunt ut labore " + "et dolore magna aliqua."; With the `\` escape sequence this could be expressed as: String text = """ Lorem ipsum dolor sit amet, consectetur adipiscing \ elit, sed do eiusmod tempor incididunt ut labore \ et dolore magna aliqua.\ """; For the simple reason that character literals and traditional string literals don't allow embedded newlines, the `\` escape sequence is only applicable to text blocks. Second, the new `\s` escape sequence simply translates to a single space (`\u0020`). Escape sequences aren't translated until after incidental space stripping, so `\s` can act as fence to prevent the stripping of trailing white space. Using `\s` at the end of each line in this example guarantees that each line is exactly six characters long: String colors = """ red \s green\s blue \s """; The `\s` escape sequence can be used in text blocks, traditional string literals, and character literals. ### Concatenation of text blocks Text blocks can be used anywhere a string literal can be used. For example, text blocks and string literals may be concatenated interchangeably: ``` String code = "public void print(Object o) {" + """ System.out.println(Objects.toString(o)); } """; ``` However, concatenation involving a text block can become rather clunky. Take this text block as a starting point: ``` String code = """ public void print(Object o) { System.out.println(Objects.toString(o)); } """; ``` Suppose it needs to be changed so that the type of `o` comes from a variable. Using concatenation, the text block that contains the trailing code will need to start on a new line. Unfortunately, the straightforward insertion of a newline in the program, as below, will cause a long span of white space between the type and the text beginning `o` : ``` String code = """ public void print(""" + type + """ o) { System.out.println(Objects.toString(o)); } """; ``` The white space can be removed manually, but this hurts readability of the quoted code: ``` String code = """ public void print(""" + type + """ o) { System.out.println(Objects.toString(o)); } """; ``` A cleaner alternative is to use `String::replace` or `String::format`, as follows: ``` String code = """ public void print($type o) { System.out.println(Objects.toString(o)); } """.replace("$type", type); ``` ``` String code = String.format(""" public void print(%s o) { System.out.println(Objects.toString(o)); } """, type); ``` Another alternative involves the introduction of a new instance method, `String::formatted`, which could be used as follows: ``` String source = """ public void print(%s object) { System.out.println(Objects.toString(object)); } """.formatted(type); ``` ### Additional Methods The following methods will be added to support text blocks; - `String::stripIndent()`: used to strip away incidental white space from the text block content - `String::translateEscapes()`: used to translate escape sequences - `String::formatted(Object... args)`: simplify value substitution in the text block Alternatives ------------ ### Do nothing Java has prospered for over 20 years with string literals that required newlines to be escaped. IDEs ease the maintenance burden by supporting automatic formatting and concatenation of strings that span several lines of source code. The `String` class has also evolved to include methods that simplify the processing and formatting of long strings, such as a method that presents a string as a [stream of lines](https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/lang/String.html#lines()). However, strings are such a fundamental part of the Java language that the shortcomings of string literals are apparent to [vast numbers of developers](https://stackoverflow.com/questions/878573/java-multiline-string). Other JVM languages have also made advances in how long and complex strings are denoted. Unsurprisingly, then, multi-line string literals have consistently been one of the most requested features for Java. Introducing a multi-line construct of low to moderate complexity would have a high payoff. ### Allow a string literal to span multiple lines Multi-line string literals could be introduced in Java simply by allowing line terminators in existing string literals. However, this would do nothing about the pain of escaping `"` characters. `\"` is the most frequently occurring escape sequence after `\n`, because of frequency of code snippets. The only way to avoid escaping `"` in a string literal would be to provide an alternate delimiter scheme for string literals. Delimiters were much discussed for [JEP 326](https://openjdk.java.net/jeps/326) (Raw String Literals), and the lessons learned were used to inform the design of text blocks, so it would be misguided to upset the stability of string literals. ### Adopt another language's multi-string literal According to [Brian Goetz](https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-March/001082.html): > Many people have suggested that Java should adopt multi-line string literals from Swift or Rust. However, the approach of “just do what language X does” is intrinsically irresponsible; nearly every feature of every language is conditioned by other features of that language. Instead, the game is to learn from how other languages do things, assess the tradeoffs they’ve chosen (explicitly and implicitly), and ask what can be applied to the constraints of the language we have and user expectations within the community we have. For [JEP 326](https://openjdk.java.net/jeps/326) (Raw String Literals), we surveyed many modern programming languages and their support for multi-line string literals. The results of these surveys influenced the current proposal, such as the choice of three `"` characters for delimiters (although there were other reasons for this choice too) and the recognition of the need for automatic indentation management. ### Do not remove incidental white space If Java introduced multi-line string literals without support for automatically removing incidental white space, then many developers would write a method to remove it themselves, or lobby for the `String` class to include a removal method. However, that implies a potentially expensive computation every time the string is instantiated at run time, which would reduce the benefit of string interning. Having the Java language mandate the removal of incidental white space, both in leading and trailing positions, seems the most appropriate solution. Developers can opt out of leading white space removal by careful placement of the closing delimiter. ### Raw string literals For [JEP 326](https://openjdk.java.net/jeps/326) (Raw String Literals), we took a different approach to the problem of denoting strings without escaping newlines and quotes, focusing on the raw-ness of strings. We now believe that this focus was wrong, because while raw string literals could easily span multiple lines of source code, the cost of supporting unescaped delimiters in their content was extreme. This limited the effectiveness of the feature in the multi-line use case, which is a critical one because of the frequency of embedding multi-line (but not truly raw) code snippets in Java programs. A good outcome of the pivot from raw-ness to multi-line-ness was a renewed focus on having a consistent escape language between string literals, text blocks, and related features that may be added in future. Testing ------- Tests that use string literals for the creation, interning, and manipulation of instances of `String` should be duplicated to use text blocks too. Negative tests should be added for corner cases involving line terminators and EOF. Tests should be added to ensure that text blocks can embed Java-in-Java, Markdown-in-Java, SQL-in-Java, and at least one JVM-language-in-Java. tools/javac: JDK-8226955: Bad EnclosingMethod Attribute on Classes Declared in Lambdas If an anonymous or local inner class is declared inside of a lambda, the `EnclosingMethod` attribute on that class refers to the synthetic lambda method rather than to the method that enclosed the original declaration. The original method should be considered as the closest lexically enclosing method. The proposed solution to this issue is to point the `EnclosingMethod` attribute of inner classes declared inside a lambda to the original enclosing method. The Java compiler was updated, so that the `EnclosingMethod` attribute of anonymous or local inner classes declared inside a lambda point to the method enclosing the declaration. The following is the related section in the Java Language Specification: JVMS 11 4.7.7: It is the responsibility of a Java compiler to ensure that the method identified via the method_index is indeed the closest lexically enclosing method of the class that contains this `EnclosingMethod` attribute. JDK-8222335: javac Rejects Class Files with Broken EnclosingMethod Attribute javac now rejects class files that have an invalid `EnclosingMethod` attribute, in which the name of the enclosing class is not a prefix of the name of the current class, as required by JLS 13.1. tools/javadoc(tool): JDK-8223253: Improved Javadoc Search The search feature in API documentation generated by Javadoc has been improved. You can now consistently search API documentation using partial terms and camel-case abbreviations. See https://docs.oracle.com/en/java/javase/14/docs/specs/javadoc/javadoc-search-spec.html for a full description of search features. JDK-8217842: Removal of Old Features from javadoc Tool The following four features have been removed from the _javadoc_ tool: _Support for generating API documentation using HTML 4:_ Support for HTML 5 was added in JDK 9 and has been the default since JDK 11. To generate API documentation that is fully compliant with the HTML 5 specification, developers should ensure that any use of HTML tags in their documentation comments is also compliant with the HTML 5 specification. _Support for the "old" javadoc API:_ This includes the API (`com.sun.javadoc`), the old standard doclet (`com.sun.tools.doclets.standard`), and the old entry point (`com.sun.tools.javadoc.Start`), all in the `jdk.javadoc` module. A new API and a new standard doclet were introduced in JDK 9, leveraging other modern modeling API such as `javax.lang.model`. The _javadoc_ tool can be programmatically invoked using the `javax.tools.DocumentationTool` API, or (for simple use) `java.util.spi.ToolProvider`. Users that just use the _javadoc_ tool to generate standard API documentation are not affected. _Support for generating documentation using HTML frames:_ It has been replaced by the "Search" feature, added in JDK 9, and by improved index files and links within pages. _Support for the `--no-module-directories` option:_ This option provided limited support for the organization used for the generated documentation by the _javadoc_ tool in JDK 9 and 10, in which the files for different modules were not grouped into separate directories. tools/javap: JDK-8225811: javap Checksum Uses SHA-256 javap includes a checksum of the contents of the class file in verbose output. The checksum is now calculated with the SHA-256 algorithm, instead of the older MD5 algorithm. tools/jlink: JDK-8226948: A jrt URI Can Only Encode Paths to Files in /modules Tree A `jrt` URL is a hierarchical URI with the syntax `jrt:/[$MODULE[/$PATH]]`. When using the `jrt` file system, a `java.net.URI` object can be created with the `java.nio.file.Path::toUri` method to encode a normalized path to a file in the `/modules` tree. A `jrt` URL cannot encode a path to a file in the `/packages` tree. The `jrt` file system provider has been changed in this release so that `toUri` fails with `IOError` when it is not possible to encode the file path as a `jrt` URI. This change might impact tools that assume a URI can be created to locate files in the `/packages` tree. Tools with paths to files in `/packages` can use the `toRealPath()` method to obtain the real path (in `/modules`) before attempting to convert the file path to a URI. xml/javax.xml.parsers: JDK-8217937: Change DOM Parser to Not Resolve EntityReference and Add Text Node with DocumentBuilderFactory.setExpandEntityReferences(false) The implementation of the `ExpandEntityReferences` feature was changed to comply with the specification of the `DocumentBuilderFactory.setExpandEntityReferences` method. Specifically, now when the method is set to `false` and encounters an entity reference, a DOM parser created by the `DocumentBuilderFactory` adds the `EntityReference` node to the DOM tree without the expanded Text node. Before the change, the implementation incorrectly added both nodes. With the change, the DOM parser no longer reads and resolves entity references when the feature `ExpandEntityReferences` is set to false. For applications that intend to avoid resolving entity references, it will work as expected. This change also affects the DOM Load and Save parser. The `entities` parameter is aligned with the `ExpandEntityReferences` feature, so that setting the `entities` parameter to `true` is equivalent to setting `ExpandEntityReferences` to `false`. In the following code snippet, the `document` will contain `EntityReference` nodes but not expanded `Text` nodes: ``` LSParser domParser = domImplementationLS.createLSParser(MODE_SYNCHRONOUS, null); domParser.getDomConfig().setParameter("entities", true); LSInput src = domImplementationLS.createLSInput(); src.setStringData(source); Document document = domParser.parse(src); ``` Because the references are not resolved, the resulting string will contain entity references without the text when the `document` is serialized: ``` LSSerializer lsSerializer = domImplementationLS.createLSSerializer(); lsSerializer.getDomConfig().setParameter("format-pretty-print", true); String result = lsSerializer.writeToString(document); ``` xml/jaxp: JDK-8224556: New Methods for Creating DOM and SAX Factories with Namespace Support New methods have been added for instantiating DOM and SAX factories with Namespace support by default. These methods are prefixed over their existing counterparts with "NS," which stands for NamespaceAware. Below is a list of the new methods: - `newDefaultNSInstance()` - `newNSInstance()` - `newNSInstance(String factoryClassName, ClassLoader classLoader)` Using these new methods, a parser created through the factory will be NamespaceAware by default. For example, the following statement: DocumentBuilder db = DocumentBuilderFactory.newDefaultNSInstance().newDocumentBuilder(); is equivalent to: DocumentBuilderFactory dbf = DocumentBuilderFactory.newDefaultInstance(); dbf.setNamespaceAware(true); DocumentBuilder db = dbf.newDocumentBuilder(); ALL FIXED ISSUES, BY COMPONENT: client-libs: JDK-8225368: broken links in java.desktop files JDK-8214252: Expanded & Collapsed nodes of a JTree look the same on GTK3 JDK-8221731: Fix doclint handling of accessibility heading in java.desktop JDK-8224876: javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedPerPixelTranslucentGradient.java fails on linux-x64 JDK-8214579: JFrame does not paint content in XVFB / X11vnc environment JDK-8220320: Remove unused old code in GraphicsEnvironment on unix JDK-8210782: Upgrade HarfBuzz to the latest 2.3.1 JDK-8217676: Upgrade libpng to 1.6.37 client-libs/2d: JDK-6933331: (d3d/ogl) java.lang.IllegalStateException: Buffers have not been created JDK-8212202: [Windows] Exception if no printers are installed. JDK-8220231: Cache HarfBuzz face object for same font's text layout calls JDK-8130266: Change the mechanism by which JDK loads the platform-specific GraphicsEnvironment class JDK-8214076: Cleanup the code related to GraphicsEnvironment/Device/Configuration JDK-8208179: Devanagari not shown with logical fonts on Windows after removal of Lucida Sans from JDK JDK-8219675: Disable harfbuzz warnings with gcc 8 JDK-8215130: Fix errors in LittleCMS 2.9 reported by GCC 8 JDK-8217731: Font rendering and glyph spacing changed from jdk-8 to jdk-11 JDK-8218854: FontMetrics.getMaxAdvance may be less than the maximum FontMetrics.charWidth JDK-8223045: GraphicsEnvironment does not detect resolution changes in multiscreen systems JDK-8222917: GraphicsEnvironment for Unix still have an unused dependency on Solaris JDK-8224825: java/awt/Color/AlphaColorTest.java fails in linux-x64 system JDK-8225007: java/awt/print/PrinterJob/LandscapeStackOverflow.java may hang JDK-8217707: JNICALL declaration breaks Splash screen functions JDK-8221412: lookupPrintServices() does not always update the list of Windows remote printers JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFont JDK-8221411: NullPointerException in RasterPrinterJob without PrinterResolution JDK-8219676: Re-enable harfbuzz warnings JDK-8218914: Support fonts installed per-user on Windows 10 JDK-8224778: test/jdk/demo/jfc/J2Ddemo/J2DdemoTest.java cannot find J2Ddemo.jar JDK-8205159: The Header of the print out displayed incomplete JDK-8214918: Unify GraphicsEnvironment.getCenterPoint()/getMaximumWindowBounds() across the platforms JDK-8222362: Upgrade to Freetype 2.10.0 client-libs/java.awt: JDK-8227919: 8213232 causes crashes on solaris sparc64 JDK-8220528: [AIX] Fix basic Xinerama and Xrender functionality JDK-8144125: [macos] java/awt/event/ComponentEvent/MovedResizedTwiceTest/MovedResizedTwiceTest.java failed automatically JDK-8061381: [macosx] Accelerators does not spelled for JMenuItems by Voice Over JDK-7141393: [macosx] CARemoteLayer code refactoring and unit test JDK-8214046: [macosx] Undecorated Frame does not Iconify when set to JDK-8214765: All TrayIcon MessageType icons does not show up with gtk3 option set JDK-8207938: At step6,Click Add button,case failed automatically. JDK-8212676: AWT SystemColor setting on CDE JDK-8217735: awt_image_GifImageDecoder_parseImage() "interlace" param has the wrong type JDK-8224771: backout RemoveDropTargetCrashTest.java fix to re-push with correct bugid JDK-8216155: C4819 warning at libfreetype sources on Windows JDK-8212700: Change the mechanism by which JDK loads the platform-specific AWT Toolkit JDK-8227392: Colors with alpha are painted incorrectly on Linux, after JDK-8214579 JDK-8177960: Deprecate the Swing Motif Look and Feel and document it as unsupported on macOS JDK-8211885: Duplicate id declarations in java.awt.geom.Path2D JDK-8220250: fix headings in java.desktop JDK-8225032: Fix some C++ conformance issues in AWT Windows code JDK-8221405: Fix Windows 32bit awt build JDK-8225487: giflib legal file is missing attribution for openbsd-reallocarray.c. JDK-8215200: IllegalArgumentException in sun.lwawt.macosx.CPlatformWindow JDK-8225376: invalid HTML in AWT_Native_Interface.html JDK-8224821: java/awt/Focus/NoAutotransferToDisabledCompTest/NoAutotransferToDisabledCompTest.java fails linux-x64 JDK-8225105: java/awt/Focus/ShowFrameCheckForegroundTest/ShowFrameCheckForegroundTest.java fails in Windows 10 JDK-8215105: java/awt/Robot/HiDPIScreenCapture/ScreenCaptureTest.java: Wrong Pixel Color JDK-8214823: Javadoc cleanup of java.awt.desktop package JDK-8215756: Memory leaks in the AWT on macOS JDK-8221246: NullPointerException within Win32ShellFolder2 JDK-8223766: Remains of ancient code in AWT initialization JDK-8216592: Removal of the class sun.awt.AWTSecurityManager JDK-8222819: Remove setting of headless property on MacOS from launcher code. JDK-8222789: Replace the usage of "Sun's Xinerama API" by the "XFree86's Xinerama API" on Solaris JDK-8223237: Replace use of string.equals("") with isEmpty() in java.desktop JDK-8225118: Robot.createScreenCapture() returns black image on HiDPI linux with gtk3 JDK-8226654: Some swing gtk regression tests fail with "java.lang.InternalError: Unable to load native GTK libraries" JDK-8214461: Some unused classes may be removed JDK-8223271: SplashScreen is still shown if defaulting to headless on MacOS JDK-8211267: StackOverflowError happened by TextField.setFont(...) JDK-8211826: StringIndexOutOfBoundsException happens via GetStringUTFRegion() JDK-8219504: Test for JDK-8211435 can be run on all platforms JDK-8224830: test/jdk/java/awt/Focus/ModalExcludedWindowClickTest/ModalExcludedWindowClickTest.java fails on linux-x64 JDK-8216318: The usage of Disposer in the java.awt.Robot can be deleted JDK-8215910: Typo in AWT InvocationEvent Method Documentation JDK-8213232: Unix/X11 setCompositionEnableNative issue JDK-8220495: Update GIFlib library to the 5.1.8 JDK-8212678: Windows IME related patch JDK-8212677: X11 default visual support for IM status window on VNC JDK-8214109: XToolkit is not correctly displayed color on 16-bit high color setting client-libs/java.awt:i18n: JDK-8213183: InputMethod cannot be used after its restarting JDK-8225182: JNI exception pending in DestroyXIMCallback of awt_InputMethod.c:1327 client-libs/java.beans: JDK-8222799: java.beans.Introspector uses an obsolete methods cache JDK-8216046: test/jdk/java/beans/PropertyEditor/Test6397609.java failing JDK-8221244: Unexpected behavior of PropertyDescription.getReadMethod for boolean properties client-libs/javax.accessibility: JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to exception JDK-8219914: Change the environment variable for Java Access Bridge logging to have a directory JDK-8190361: Incorrect version info in jaccessinspector.exe and jaccesswalker.exe JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled JDK-6714324: Removing a component from a JTabbedPane does not clear its accessibleParent JDK-7106851: Test should not use System.exit client-libs/javax.sound: JDK-8222438: Drop of outdated logging in the com.sun.media.sound package JDK-8221445: FastSysexMessage constructor crashes MIDI receiption thread JDK-8224056: Fix some assignments of string literals to LPSTR (instead of LPCSTR) JDK-8221436: Incorrect check of package in Line.Info.toString() JDK-8222083: Support of "64-bit IEEE floating point" encoding for the AU file format client-libs/javax.swing: JDK-8225144: [macos] In Aqua L&F backspace key does not delete when Shift is pressed JDK-8213071: [macos] The focus disappears after pressing return to close the "That was a pretty good movie!" dialog. JDK-8216971: [macosx swing] For JCheckBoxMenuItem actionPerformed() is called twice, when apple.laf.useScreenMenuBar=true and modifier is InputEvent.META_DOWN_MASK JDK-8226964: [Yaru] GTK L&F: There is no difference between menu selected and de-selected JDK-8225146: Accessibility issues in javax/swing/plaf/nimbus/doc-files/properties.html JDK-8218599: Add test group jdk_client_sanity under jdk_desktop group JDK-8219552: bump jtreg requiredVersion to b14 in test/jdk/sanity/client/ JDK-8222519: ButtonDemoScreenshotTest fails randomly with "still state to be reached" JDK-8217235: Create automated test for SwingSet ColorChooserDemoTest JDK-6684386: ElementIterator javadoc bug JDK-8214471: Enable different look and feel tests in SwingSet3 demo test ToolTipDemoTest JDK-8226783: GTK is not being returned as the System L&F on Gnome. JDK-8225423: GTK L&F: JSplitPane: There is no divider shown JDK-8218674: HTML Tooltip with "img src=" on component doesn't show JDK-8221661: javax.swing.text.View.getPreferredSpan​(int axis) JDK-8225511: javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedTranslucentPerPixelTranslucentGradient.java fails in linux-x64 JDK-8211703: JInternalFrame : java.lang.AssertionError: cannot find the internal frame JDK-8218473: JOptionPane display issue with GTKLookAndFeel JDK-8218472: JProgressBar display issue with GTKLookAndFeel JDK-8218470: JScrollBar display issue with GTKLookAndFeel JDK-8218469: JSlider display issue with slider for GTKLookAndFeel JDK-8215396: JTabbedPane preferred size calculation is wrong for SCROLL_TAB_LAYOUT JDK-8212904: JTextArea line wrapping incorrect when using UI scale JDK-8218479: JTextPane display issue with GTKLookAndFeel JDK-8218917: KeyEvent.getModifiers() returns inconsistent values for ALT keys JDK-8212701: remove sun.desktop property from launcher code JDK-8219156: RTFEditorKit writes background color but doesn't read JDK-8203627: Swing applications with JRadioButton and JCheckbox fail to render correctly when using GTK3 and the GTK L&F JDK-8220349: The fix done for JDK-8214253 have caused issues in JTree behaviour JDK-8214112: The whole text in target JPasswordField image are not selected. JDK-8214111: There is no icon in all JOptionPane target image JDK-8214253: Tooltip is transparent rather than having a black background JDK-8215909: Typo in Swing ProcessMouseEvent method documentation JDK-8216353: Use utility APIs introduced in org/netbeans/jemmy/util/LookAndFeel class in client sanity test cases JDK-8213781: web page background renders blue in JEditorPane JDK-8214702: Wrong text position for whitespaced string in printing Swing text core-libs: JDK-8216401: Allow "file:" URLs in Class-Path of local JARs JDK-8214077: ARM32: test java/io/File/SetLastModified.java fails on ARM32 JDK-8211941: Enable checking/ignoring of non-conforming Class-Path entries JDK-8223553: Fix code constructs that do not compile with the Eclipse Java Compiler JDK-8220261: fix headings in java.base JDK-8220072: GCC 8.3 reports errors in java.base JDK-8220598: Malformed copyright year range in a few files in java.base JDK-8215217: OpenJDK source has too many swear words JDK-8223593: Refactor code for reallocating storage JDK-8218022: Repeated words typos in java.base JDK-8205626: Start of release updates for JDK 13 JDK-8225315: test java/util/ArrayDeque/WhiteBox.java isn't part of the jdk_collections test group JDK-8213223: Umbrella: JDK 13 terminal deprecations JDK-8228450: unicode.md and icu.md text should be pre-formatted JDK-8215798: Use {@systemProperty} for org.openjdk.java.util.stream.tripwire system property JDK-8212528: Wrong cgroup subsystem being used for some CPU Container Metrics core-libs/java.io: JDK-8078860: (spec) InputStream.read(byte[] b, int off, int len) claims to not affect element b[off] JDK-8221597: A typo in the Java API doc for File.getUsableSpace() JDK-8221262: Cleanups in UnixFileSystem/WinNTFileSystem implementation classes JDK-8219992: Correct the documentation of PrintWriter to refer to System.lineSeparator JDK-8219196: DataOutputStream.writeUTF may throw unexpected exceptions JDK-8216172: File.renameTo(File dest) should check for NPE at the very beginning JDK-8218280: LineNumberReader throws "Mark invalid" exception if CRLF straddles buffer. JDK-8215412: Optimize PrintStream.println methods JDK-6307456: UnixFileSystem_md.c use of chmod() and access() should handle EINTR signal appropriately (unix) JDK-8216067: Unused local vars in windows/native/libjava/io_util_md.c JDK-8214565: Use {@systemProperty} for definitions of system properties core-libs/java.io:serialization: JDK-8226605: Accessibility issues in specs/serialization/*.html JDK-6996807: FieldReflectorKey hash code computation can be improved JDK-8220166: Performance regression in deserialization (4-6% in SPECjbb) JDK-8202675: Replace process-wide terminology in serial filtering to be consistent JDK-8227541: Serial spec should be updated to reflect API generification JDK-6394787: Typos in javadoc of OIS.readObjectOverride and OOS.writeObjectOverride core-libs/java.lang: JDK-8213192: (process) Change the Process launch mechanism default on Linux to be posix_spawn JDK-8216134: (process) ProcessBuilder startPipeline does not hide piped streams JDK-8224986: (str) optimize StringBuilder.append(CharSequence, int, int) for String arguments JDK-8225353: Add @jls links to java.lang.Enum JDK-8223078: Add microbenchmark for array copying/clearing/resizing JDK-8197927: Allow the system property `java.vendor.version` to be undefined JDK-8221836: Avoid recalculating String.hash when zero JDK-8221723: Avoid storing zero to String.hash JDK-8225314: broken links in java.base JDK-8217339: ClassCircularityError loading NumberFormatProvider JDK-8218386: Correct the SE version in j.l.Character JDK-8221267: Document the jdk.net.URLClassPath.showIgnoredClassPathEntries system property JDK-8220238: Enhancing j.l.Runtime/System::gc specification with an explicit 'no guarantee' statement JDK-8224175: Fix inconsistencies in @jls and @jvms tags JDK-8221921: Implement size() / isEmpty() in immutable collections JDK-8215017: Improve String::equals warmup characteristics JDK-8223777: In posix_spawn mode, failing to exec() jspawnhelper may not result in an error JDK-8216205: Java API documentation formatting error in System.getEnv() JDK-8224174: java.lang.Number has a default constructor JDK-8080569: java/lang/ProcessBuilder/DestroyTest.java fails with "RuntimeException: Process terminated prematurely" JDK-8210788: Javadoc for Thread.join(long, int) should specify that it waits forever when both arguments are zero JDK-8224783: Javadoc of String strip methods uses link where linkplain would be better JDK-8216413: Long.parseLong() is specified to throw unless string contains parsable {@code int}; should be {@code long} JDK-8226709: MethodTypeDesc::resolveConstantDesc needs access check per the specification JDK-8218726: Minor Throwable.printStackTrace() typos JDK-8224181: On child process spawn, child may write to random file descriptor instead of the fail pipe JDK-8222029: Optimize Math.floorMod JDK-8222955: Optimize String.replace(CharSequence, CharSequence) for common cases JDK-8225675: Outdated citation of JLS in java.lang.ref.Reference JDK-8220684: Process.waitFor(long, TimeUnit) can return false for a process that exited within the timeout JDK-8220237: ProcessBuilder API documentation typo JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull JDK-8222151: refactoring: enhancements to java.lang.Class::methodToString and java.lang.Class::getTypeName JDK-8205131: remove Runtime trace methods JDK-8074817: Resolve disabled warnings for libverify JDK-8203444: String::formatted (Preview) JDK-8223775: String::stripIndent (Preview) JDK-8223780: String::translateEscapes (Preview) JDK-8225448: String::translateEscapes javadoc has accessibility issues JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified JDK-8218227: StringBuilder/StringBuffer constructor throws confusing NegativeArraySizeException JDK-8221431: Support for Unicode 12.1 JDK-8218228: The constructor StringBuffer(CharSequence) violates spec for negatively sized argument JDK-8219197: ThreadGroup.enumerate() may return wrong value JDK-8223730: URLClassLoader.findClass() can throw IndexOutOfBoundsException core-libs/java.lang.invoke: JDK-8220282: Add MethodHandle tests on accessing final fields JDK-8219487: j.l.c.ClassDesc spec should contain precise assertions for one parameter's methods JDK-8219480: j.l.c.ClassDesc::arrayType(int rank) throws IllegalArgumentException if rank = 0 JDK-8219483: j.l.c.ClassDesc::nested(String, String...) doesn't throw NPE if any arg is null JDK-8223725: j.l.c.MethodHandleDesc::of throws undocumented exception IllegalArgumentException JDK-8223726: j.l.c.MethodTypeDesc spec should contain precise assertions for one parameter's methods JDK-8223723: j.l.c.MethodTypeDesc.dropParameterTypes​ throws the undocumented exception: IllegalArgumentException JDK-8223803: j.l.c.MethodTypeDesc::insertParameterTypes​ doesn't control type of parameters JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for static final field JDK-8213234: Move LambdaForm.Hidden to jdk.internal.vm.annotation JDK-8222852: Reduce String concat combinator tree shapes by folding constants into prependers JDK-8223454: Reduce String concatenation shapes by folding initialLengthCoder into last mixer JDK-8222484: Specialize generation of simple String concatenation expressions JDK-8223914: specification of j.l.c.MethodTypeDesc::of should document better the exceptions thrown JDK-8222895: StackOverflowError in custom security manager that relies on ClassSpecializer core-libs/java.lang.module: JDK-8221473: Configuration::reads can use Set.copyOf core-libs/java.lang:class_loading: JDK-8222144: BuiltinClassLoader should create the CodeSource for jrt URLs lazily JDK-8218419: Can't get annotations that are present on packages in -Xbootclasspath/a core-libs/java.lang:reflect: JDK-7086604: (reflect) Clarifications to javadoc for getGeneric*Type methods in j.l.r JDK-8227252: [aix] Disable jdk/java/lang/reflect/exeCallerAccessTest JDK-8225465: Add @jls tags to receiver type methods JDK-8224012: AnnotatedType implementations of hashCode() lead to StackOverflowError JDK-8222082: Build of test/jdk/java/lang/reflect/exeCallerAccessTest/exeCallerAccessTest.c still failing on Windows JDK-8042748: Clarify exception thrown by ParameterizedTypeImpl.validateConstructorArguments() JDK-8222111: exeCallerAccessTest.c fails to build: control reaches end of non-void function JDK-8221530: Field::get and reflective member access not handling caller = null when invoked by JNI code with no java frames on stack JDK-8198526: getAnnotatedOwnerType does not handle static nested classes correctly JDK-8181869: getAnnotatedParameterTypes​() specification should be clarified JDK-8222448: java/lang/reflect/PublicMethods/PublicMethodsTest.java times out JDK-8219378: NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized JDK-8217000: Refactor Class::methodToString JDK-8222078: test/jdk/java/lang/reflect/exeCallerAccessTest/exeCallerAccessTest.c build fails after 8221530 core-libs/java.math: JDK-8215759: [test] java/math/BigInteger/ModPow.java can throw an ArithmeticException JDK-8183912: java.math.BigDecimal.movePointLeft() should return this if called with zero argument JDK-8225117: java/math/BigInteger/SymmetricRangeTests.java fails with ParseException core-libs/java.net: JDK-8225424: Add jdk.net.usePlainSocketImpl runs to a couple of tests JDK-8220673: Add test library support for determining platform IP support JDK-8220719: Allow other named NetPermissions to be used JDK-8215990: Avoid using reflection to create common default URLStreamHandlers JDK-8216478: Cleanup HttpResponseImpl back reference to HttpConnection JDK-8216417: cleanup of IPv6 scope-id handling JDK-8216498: Confusing and unneeded wrapping of SSLHandshakeException JDK-8153508: ContentHandler API contains link to private contentPathProp JDK-8220575: Correctly format test URI's that contain a retrieved IPv6 address JDK-8217364: Custom URLStreamHandler for jrt or file protocol can override default handler. JDK-8224014: Don't run test/jdk/java/net/NetworkInterface/IPv4Only.java in IPv6 only environment JDK-8223532: Don't try creating IPv4 sockets in NetworkInterface.c if IPv4 is not supported JDK-8216978: Drop support for pre JDK 1.4 SocketImpl implementations JDK-8217451: ExtendedSocketOptions should encapsulate support for SO_FLOW_SLA JDK-8007606: Handle realloc() failure in unix/native/libnet/net_util_md.c correctly JDK-8223737: HostsFileNameService doesn't handle IPv6 literal addresses correctly JDK-8217237: HttpClient does not deal well with multi-valued WWW-Authenticate challenge headers JDK-8222527: HttpClient doesn't send HOST header when tunelling HTTP/1.1 through http proxy JDK-8221395: HttpClient leaving connections in CLOSE_WAIT state until Java process ends JDK-8217094: HttpClient SSL race if a socket IOException is raised before ALPN is available JDK-8217264: HttpClient: Blocking operations in mapper function do not work as documented JDK-8217627: HttpClient: The API documentation of BodySubscribers::mapping promotes bad behavior JDK-8216561: HttpClient: The logic of retry on connect exception is inverted JDK-8216974: HttpConnection not returned to the pool after 204 response JDK-8218554: HttpServer: allow custom handlers to request that the connection be closed after the exchange. JDK-8217311: Improve Exception thrown when MulticastSocket.setInterface fails on AIX(Unix) JDK-8220585: Incorrect code in MulticastSocket sample code JDK-8220663: Incorrect handling of IPv6 addresses in Socket(Proxy.HTTP) JDK-8223214: Inet6AddressImpl.loopbackAddress() should choose loopback address that is available JDK-8222562: IPv6 only systems fail on setsockopt(IPV6_V6ONLY, 0) JDK-8224477: java.net socket types new-style socket option methods - spec and impl mismatch JDK-8225060: java.net.DefaultInterface invokes NetworkInterface::getInetAddresses without doPriv JDK-8225037: java.net.JarURLConnection::getJarEntry() throws NullPointerException JDK-8223457: java.net.ServerSocket protected constructor should throw NPE if impl null JDK-8224730: java.net.ServerSocket::toString not invoking checkConnect JDK-8194231: java/net/DatagramSocket/ReuseAddressTest.java failed with java.net.BindException: Address already in use: Cannot bind JDK-8217882: java/net/httpclient/MaxStreams.java failed once JDK-8217903: java/net/httpclient/Response204.java fails with 404 JDK-8228434: jdk/net/Sockets/Test.java fails after JDK-8227642 JDK-8218559: JEP 353: Reimplement the Legacy Socket API JDK-8170494: JNI exception pending in PlainDatagramSocketImpl.c JDK-8225651: Missed the `@` in a couple of code tags of SocketImpl JDK-8226730: Missing `@` in code tags JDK-8216355: missing NULL checks in libnet in interface iteration and potential resource leak in getMacAddress JDK-8218882: NET_Writev is declared, NET_WriteV is defined JDK-8220493: Prepare Socket/ServerSocket for alternative platform SocketImpl JDK-8221481: Reimplement the Legacy Socket API JDK-8220083: Remove hard-coded 127.0.0.1 loopback address in JDK networking tests JDK-8216986: Remove unused code from SocksSocketImpl JDK-8223652: Rename IPSupport.skipIfCurrentConfigurationIsInvalid() JDK-8225426: Replace plain with system-default in Socket and ServerSocket JDK-8223145: Replace wildcard address with loopback or local host in tests - part 1 JDK-8224204: Replace wildcard address with loopback or local host in tests - part 10 JDK-8224603: Replace wildcard address with loopback or local host in tests - part 11 JDK-8224761: Replace wildcard address with loopback or local host in tests - part 12 JDK-8224865: Replace wildcard address with loopback or local host in tests - part 13 JDK-8225512: Replace wildcard address with loopback or local host in tests - part 15 JDK-8223463: Replace wildcard address with loopback or local host in tests - part 2 JDK-8223465: Replace wildcard address with loopback or local host in tests - part 3 JDK-8223573: Replace wildcard address with loopback or local host in tests - part 4 JDK-8223632: Replace wildcard address with loopback or local host in tests - part 5 JDK-8223638: Replace wildcard address with loopback or local host in tests - part 6 JDK-8223798: Replace wildcard address with loopback or local host in tests - part 7 JDK-8223856: Replace wildcard address with loopback or local host in tests - part 8 JDK-8224035: Replace wildcard address with loopback or local host in tests - part 9 JDK-8221098: Run java/net/URL/HandlerLoop.java in othervm mode JDK-8213912: Semantic typo in HttpExchange.java JDK-8216988: ServerSocket.implAccept should include warnings about Socket type/state JDK-8225214: Socket.getOption(SocketOption) not returning the expected type for the StandardSocketOptions.SO_LINGER JDK-8224081: SOCKS v4 tests require IPv4 JDK-8217740: SocksIPv6Test.java compilation error JDK-8219446: Specify behaviour of timeout accepting methods of Socket and ServerSocket if timeout is negative JDK-8223716: sun/net/www/http/HttpClient/MultiThreadTest.java should be more resilient to unexpected traffic JDK-8227422: sun/net/www/protocol/file/DirPermissionDenied.java failed on Windows 2016 because DirPermissionDenied directory has no read permission JDK-8218133: sun/net/www/protocol/http/ProtocolRedirect.java failed with "java.net.ConnectException" JDK-8170705: sun/net/www/protocol/http/StackTraceTest.java fails intermittently with Invalid Http response JDK-8229018: Switching to an infinite socket timeout on Windows leads to high CPU load JDK-8224248: test/jdk/java/net/InetAddress/CheckJNI.java assumes 127.0.0.1 is available JDK-8224018: test/jdk/java/net/ipv6tests/{Tcp,Udp}Test.java assume IPv4 is available JDK-8224256: test/jdk/java/security/SecureClassLoader/DefineClass.java hardcodes 127.0.0.1 JDK-8182992: Typo in DatagramPacket constructor API doc JDK-8220480: Typo in java.net.http.HttpResponse.BodySubscriber documentation JDK-8184315: Typo in java.net.JarURLConnection.getCertificates() method documentation JDK-8179549: Typo in network properties documentation JDK-8223921: Update SocketReadWrite benchmark JDK-8223880: Update sun/net/ftp/FtpURL.java and sun/net/ftp/FtpURLConnectionLeak.java to work with IPv6 addresses JDK-8224973: URLStreamHandler.openConnection(URL,Proxy) - spec and implementation mismatch JDK-8219202: Use Unsynchronized StringBuilder in sun.net.www.ParseUtil JDK-8215912: Various Typos in java.net Method Documentation JDK-8217429: WebSocket over authenticating proxy fails to send Upgrade headers JDK-8221406: Windows 32bit build error in NetworkInterface_winXP.c core-libs/java.nio: JDK-8065262: (bf spec) CharBuffer.chars() should make it clearer that the sequence starts from the buffer position JDK-5029431: (bf) Add absolute bulk put and get methods JDK-5071718: (bf) Add ByteBuffer.slice(int index, int length) JDK-8220614: (bf) Buffer absolute slice methods should use Objects.checkFromIndexSize() JDK-8011135: (bf) CharBuffer.put(String) is slow because of String.charAt() call for each char JDK-8219597: (bf) Heap buffer state changes could provoke unexpected exceptions JDK-8219876: (bf) Improve IndexOutOfBoundsException messages in $Type$Buffer classes JDK-8226203: (bf) MappedByteBuffer.force method may have no effect on implementation specific map modes JDK-8221696: (bf) MappedByteBuffer.force method to specify range JDK-5043362: (bf) NewDirectByteBuffer always has order ByteOrder.BIG_ENDIAN JDK-8048192: (bf) Out of direct buffer memory message should include the limits JDK-8217461: (ch) Add Net.available to return the number of bytes in the socket input buffer. JDK-8223353: (ch) Change channel close implementation to not wait for I/O threads JDK-8222774: (ch) Replace uses of stateLock and blockingLock with j.u.c. locks JDK-8221397: (fc) Support implementation-defined Map Modes JDK-8218875: (fs) Add FileSystems.newFileSystem(Path, Map) method JDK-8218418: (fs) Files.createSymbolicLink should use SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE (win) JDK-8224617: (fs) java/nio/file/FileStore/Basic.java found filesystem twice JDK-8220793: (fs) No support for changing modification time of symlink JDK-8220738: (sc) Move ServerSocketChannelImpl remaining native method to Net JDK-8217500: (sc) Move SocketChannelImpl's remaining native methods to Net JDK-8221252: (sc) SocketChannel and its socket adaptor need to handle connection reset JDK-8215472: (zipfs) Cleanups in implementation classes of jdk.zipfs and tests JDK-8222440: (zipfs) JarFileSystem does not correctly handle versioned entries if no root entry is present JDK-8223597: (zipfs) jdk/nio/zipfs/ZipFSTester.java RuntimeException: CHECK_FAILED! (getAttribute.crc failed 6af4413c vs 0 ...) JDK-8222807: (zipfs) OutOfMemory on compiling with darcula.jar in classpath JDK-8222532: (zipfs) Performance regression when writing ZipFileSystem entries in parallel JDK-8222276: (zipfs) Refactoring and cleanups to prepare for JDK-8213031 JDK-8211919: (zipfs) ZipDirectoryStream should provide a stream of paths that are relative to the directory JDK-8224042: Add private alignDown method to MappedByteBuffer JDK-8221824: Build failure with MSVS 2013 after JDK-8218418 JDK-8220477: Channels.newWriter() does not close if underlying channel throws an IOException JDK-8223015: Cleanups for zipfs tests JDK-8215467: Files.isHidden should return true for hidden directories on Windows JDK-8223178: Improve FileSystems.newFileSystem example with map factory methods JDK-8223442: java/nio/channels/SocketChannel/AdaptorStreams.java testConcurrentTimedReadWrite3(): failure JDK-8182117: jdk.zipfs should document the "create" and "encoding" properties JDK-8210469: missing doPrivileged and permission in jdk.zipfs JDK-8221852: SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE should be selected at runtime, not build time JDK-8218460: Test generation scripts do not invoke stream preprocessor correctly JDK-8224645: Test java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with NoSuchElementException JDK-8224019: test/jdk/java/nio/channels/DatagramChannel/BasicMulticastTests.java assumes IPv4 is always available JDK-8215372: test/jdk/java/nio/file/DirectoryStream/Basic.java not correct when using a glob JDK-8214563: Use {@systemProperty} in specification of system properties in java.nio packages core-libs/java.nio.charsets: JDK-8217880: AIX build issue after JDK-8214533 JDK-8216140: Correct UnicodeDecoder U+FFFE handling JDK-8214533: IBM-29626C is required for AIX default charset JDK-8220281: IBM-858 alias name is missing on IBM00858 charset JDK-7061590: Javadoc issues in Charset and StandardCharsets core-libs/java.rmi: JDK-8217412: deprecate rmic for removal JDK-8217405: rmic should reject class files with preview features enabled JDK-4887513: Typo in RMIFailureHandler interface doc page core-libs/java.sql: JDK-8225306: bad headings in java.sql.rowset SyncProvider.java JDK-8225322: Broken links in java.sql JDK-8215911: Various Typos in SQL Method Documentation core-libs/java.text: JDK-8217254: CompactNumberFormat:: CompactNumberFormat​() constructor does not comply with spec. JDK-8217721: CompactNumberFormat:: format​() method spec for IAEx is not complaint JDK-8227127: Era designator not displayed correctly using the COMPAT provider JDK-8216969: ParseException thrown for certain months with russian locale JDK-8218948: SimpleDateFormat :: format - Zone Names are not reflected correctly during run time core-libs/java.time: JDK-8224560: (tz) Upgrade time-zone data to tzdata2019a JDK-8222668: Add @since tag to JapaneseEra.REIWA JDK-8223773: DateTimeFormatter Fails to throw an Exception on Invalid HOUR_OF_AMPM JDK-8225580: tzdata2018i integration causes test failures on jdk-13 core-libs/java.util: JDK-8217969: Base64.Decoder.decode methods do not need to throw OOME due to integer overflow JDK-8210583: Base64.Encoder incorrectly throws NegativeArraySizeException JDK-8223112: Clarify operational semantics of java.util.Objects.equals() JDK-8225094: Fix minor HTML issues in jdk.zipfs JDK-8219548: Improve src/java.base/share/classes/java/util/spi/ToolProvider.java null parameter checking JDK-8225397: Integer value miscalculation in toString() method of BitSet JDK-8220005: java/util/Arrays/TimSortStackSize2.java times out JDK-8220613: java/util/Arrays/TimSortStackSize2.java times out with fastdebug build JDK-8224240: Properties.load fails to throw IAE on malformed unicode in certain circumstances JDK-8221981: Simplify Map/List/Set.of() implementation JDK-8221980: Simplify Optional implementation JDK-8224202: Speed up Properties.load JDK-8217777: TEST_BUG: jdk/java/util/prefs/ExportSubtree.java passes even when test should fail core-libs/java.util.concurrent: JDK-8223379: Clarify ForkJoinPool.getStealCount() javadoc JDK-8222930: ConcurrentSkipListMap.clone() shares size variable between original and clone JDK-8224698: ConcurrentSkipListMap.java does not compile with the Eclipse Java Compiler JDK-8221120: CopyOnWriteArrayList.set should always have volatile write semantics JDK-8220248: fix headings in java.util.concurrent JDK-8224176: Fix inconsistencies in @jls tags in java.util.concurrent JDK-8215359: InnocuousForkJoinWorkerThread.setContextClassLoader needlessly throws JDK-8220478: java/util/concurrent/ConcurrentHashMap/ToArray.java timed out intermittently JDK-8215249: Miscellaneous changes imported from jsr166 CVS 2019-02 JDK-8219138: Miscellaneous changes imported from jsr166 CVS 2019-05 JDK-8223245: Miscellaneous changes imported from jsr166 CVS 2019-06 JDK-8215363: needless signals in ForkJoinPool JDK-8221892: ThreadPoolExecutor: Thread.isAlive() is not equivalent to not being startable core-libs/java.util.jar: JDK-8214712: Archive Attributes$Name.KNOWN_NAMES JDK-8225189: assert(!JavaThread::current()->in_critical()) failed: Would deadlock JDK-8215192: bad table headers in pack-spec.md JDK-8216362: Better error message handling when there is an invalid Manifest JDK-8221687: Deprecated j.u.jar.Attributes.Name attributes accidentally set to null JDK-8066619: Fix deprecation warnings in java.util.jar JDK-8226592: Fix HTML in table for jdk.zipfs module-info JDK-8215922: jar spec is not precise when describing jar file re-signing JDK-8217393: java.util.jar.Attributes:equals() javadoc is not accurate core-libs/java.util.logging: JDK-8195716: BootstrapLoggerTest : Executor still alive JDK-8220262: fix headings in java.logging JDK-8217353: java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java fails with Unexpected reference: java.lang.ref.WeakReference JDK-8216363: NullPointerException in java.util.logging.Handler#isLoggable core-libs/java.util.regex: JDK-8225179: (regex) Minor Pattern cleanup JDK-8225198: Optimize regex tree for greedy quantifiers of type {N,} JDK-8224789: Parsing repetition count in regex does not detect numeric overflow JDK-8223174: Pattern.compile() can throw confusing NegativeArraySizeException JDK-8225061: Performance regression in Regex JDK-8222978: Upgrade the extended grapheme cluster support to the latest Unicode level. core-libs/java.util:collections: JDK-8215995: Add specialized toArray methods to immutable collections JDK-8227368: EnumSet.class serialization broken in JDK 9+ JDK-8221924: get(null) on single-entry unmodifiable Map returns null instead of throwing NPE JDK-8214687: Optimize Collections.nCopies().hashCode() and equals() JDK-8210280: Unnecessary reallocation when invoking HashMap.putAll() core-libs/java.util:i18n: JDK-8221701: Archive constant BaseLocales JDK-8226876: Assertion in sun/util/locale/provider/CalendarDataUtility on Windows after JDK-8218960 JDK-8219890: Calendar.getDisplayName() returns empty string for new Japanese Era on some locales JDK-8224105: Cannot parse JapaneseDate string on some specified locales JDK-8218960: CONFIG level logging statements printed in CLDRCalendarDataProviderImpl.java even when default log Level is INFO JDK-8174268: Declare a public field in JapaneseEra for the era starting May 2019 JDK-8209175: Handle 'B' character introduced in CLDR 33 JDK update for Burmese (my) locale JDK-8220227: Host Locale Provider getDisplayCountry returns error message under non-English Win10 JDK-8220037: Inconsistencies of generated timezone files between Windows and Linux JDK-8228971: Locale API doc has redundant hyphens for some parameters JDK-8218781: Localized names for Japanese Era Reiwa in COMPAT provider JDK-8217609: New era placeholder not recognized by java.text.SimpleDateFormat JDK-8205432: Replace the placeholder Japanese era name JDK-8226869: Test java/util/Locale/LocaleProvidersRun.java should enable assertions JDK-8221432: Upgrade CLDR to Version 35.1 JDK-8222980: Upgrade IANA Language Subtag Registry to Version 2019-04-03 JDK-8220224: With CLDR provider, NumberFormat.format could not handle locale with number extension correctly. JDK-8217366: ZoneStrings are not populated for all the Locales core-libs/javax.annotation.processing: JDK-8225077: fix references to broken link in java.compiler module JDK-8146726: Improve AbstractProcessor to issue warnings for repeated information JDK-8216335: Minor cleanups to javax.annotation.processing and javax.lang.model javadoc JDK-8222378: Provide mechanism to query preview feature status for annotation processors JDK-8222817: Refactor printing processor to use streams core-libs/javax.lang.model: JDK-8224687: Add clarifying overrides of Element.asType to more specific subinterfaces JDK-8205393: Add SourceVersion.RELEASE_13 JDK-8222430: Add tests for ElementKind predicates JDK-8219805: Cross-link javax.lang.model.{type, element} packges to utility interfaces JDK-8216404: Elements.getPackageOf should handle modules JDK-8224628: Note that type parameters are not visited by ElementScanners JDK-8208371: Provided supported mechanims to create a ModuleElement for an unnamed module core-libs/javax.naming: JDK-8220252: fix headings in java.naming JDK-8225129: Fix minor HTML issues in java.naming JDK-8139965: Hang seen when using com.sun.jndi.ldap.search.replyQueueSize JDK-8214440: ldap over a TLS connection negotiate failed with "javax.net.ssl.SSLPeerUnverifiedException: hostname of the server '' does not match the hostname in the server's certificate" core-libs/javax.sql: JDK-8220253: fix headings in java.sql.rowset core-libs/jdk.nashorn: JDK-8222528: Fix javadoc headers in Nashorn sources JDK-8227391: Update double-conversion to version 3.1.5 core-svc: JDK-8220579: [Containers] SubSystem.java out of sync with osContainer_linux.cpp JDK-8219721: jcmd from earlier release will hang attaching to VM with JDK-8215622 applied core-svc/debugger: JDK-8226596: Accessibility errors in jdwp-protocol.html JDK-8224673: Adjust permission for delayed starting of debugging JDK-8214582: BasicJDWPConnectionTest.java: RuntimeException: Could not detect port from '' JDK-8225493: broken links in specs/jpda/architecture.html and specs/jpda/jpda.html JDK-8222821: com/sun/jdi/ExceptionEvents.java failed JDK-8218166: com/sun/jdi/SimulResumerTest.java failure JDK-8163127: Debugger classExclusionFilter does not work correctly with method references JDK-8215550: Debugger does not work after reattach JDK-8226593: Fix HTML in com/sun/jdi/doc-files/signature.html JDK-8226608: Hide the onjcmd option from the help output JDK-6504660: HPI panic callback is dead code JDK-8225309: HTML issues in jdk.jdi module JDK-8215571: jdb does not include jdk.* in the default class filter JDK-8218941: jdb should support a dbgtrace command that acts the same as the dbgtrace command line option JDK-8219143: jdb should support breakpoint thread filters JDK-8218947: jdb threads command should print threadID in decimal, not hex JDK-8220030: JdbStopThreadidTest.java failed due to "Unexpected IO error while writing command 'quit' to jdb stdin stream" JDK-8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 is not alive" JDK-8222741: jdi/EventQueue/remove/remove004 fails due to VMDisconnectedException JDK-8220456: jdi/EventQueue/remove_l/remove_l004 failed due to "TIMEOUT while waiting for event" JDK-8146986: JDI: Signature lookups for unprepared classes can take a long time JDK-8218754: JDK-8068225 regression in JDIBreakpointTest JDK-8214122: JDWP is broken on 32 bit Windows: transport library missing onLoad entry JDK-8184770: JDWP support for IPv6 JDK-8221707: JDWP support for IPv6 - spec update JDK-8214854: JDWP: Unforseen output truncation in logging JDK-8224028: loop initial declarations introduced by JDK-8184770 JDK-8219388: Misleading log message "issuspended002a debuggee launched" JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out JDK-8225682: Reference to JNI spec on java.sun.com JDK-8219002: Some comments and error messages refer to VMDisconnectException JDK-8222529: sun.jdwp.listenerAddress agent property uses wrong encoding JDK-8201252: unquarantine nsk/jdi/ThreadReference/resume/resume001 JDK-8222828: vmTestbase/nsk/jdi/BScenarios/multithrd/tc02x004/TestDescription.java failed JDK-8222422: vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses tests failed with Unexpected Exception: null JDK-8222749: vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter001/TestDescription.java failed with "eventSet1.size() != 3 :: 2" JDK-8222667: vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter002/TestDescription.java failed with "event IS NOT a breakpoint" JDK-8218464: vmTestbase/nsk/jdi/VirtualMachine/allThreads/allthreads001/TestDescription.java failed core-svc/java.lang.instrument: JDK-8183273: Clarify Instrumentation interface should not be implemented outside java.instrument module JDK-8220257: fix headings in java.instrument JDK-8220355: Improve assertion texts and exception messages in eventHandlerVMInit JDK-8220474: Incorrect GPL header in src/java.instrument/share/classes/java/lang/instrument/package-info.java JDK-8225207: redundant

in Instrumentation.java core-svc/java.lang.management: JDK-8209455: [error-prone] JdkObsolete in jdk.management.agent JDK-8220251: fix headings in java.management JDK-8215966: GeneratePropertyPassword.sh uses bash syntax core-svc/javax.management: JDK-8225679: reference to http://java.sun.com/products/JavaManagement/download.html JDK-8221303: sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java fails due to java.rmi.server.ExportException: Port already in use core-svc/tools: JDK-8215622: Add dump to file support for jmap –histo JDK-8225324: Bad HTML in jdk.jfr module-info.java JDK-8203026: java.rmi.NoSuchObjectException: no such object in table JDK-8222491: jcmd can fail converting UTF8 output to strings JDK-8225543: Jcmd fails to attach to the Java process on Linux using the main class name if whitespace options were used to launch the process JDK-8221730: jcmd process name matching broken JDK-8221164: jstatLineCounts tests need to be more resilent for NaN outputs JDK-8221694: jstatLineCounts1 needs to be NaN resilient JDK-8222533: jtreg test jdk/internal/platform/cgroup/TestCgroupMetrics.java fails on SLES12.3 linux ppc64le machine JDK-8220175: serviceability/dcmd/framework/VMVersionTest.java fails with a timeout JDK-8220295: sun/tools/jps/TestJps.java still timing out docs: JDK-8222301: Incorporate JDK 12 comments in JDK 13 java man page JDK-8221204: Link "Java SE Documentation" on the Complete Dialog redirected to 404 error page docs/guides: JDK-8230786: "Serialization Filtering" guide typos JDK-8229042: Add ECDSA algorithms to the SunMSCAPI provider doc JDK-8134981: Document JDK supported permissions in security permissions guide JDK-8223649: Document the com.sun.security.crl.readtimeout system property JDK-8017092: Update the PKCS#11 Reference Guide to document all the supported configuration flags. JDK-8223311: Update use of "-Djava.security.debug=help" option globalization: JDK-8222969: Migrate RuleBasedCollatorTest to JDK Repo globalization/locale-data: JDK-8206879: Currency decimal marker incorrect for Peru globalization/translation: JDK-8228778: JDK 13 L10n resource files update - msg drop 20 JDK-8227009: JDK 13 L10n resource files update - msgdrop 10 JDK-8228397: Missing license copyright header in some properties files JDK-8228623: Update copyright year to 2019 for several java properties file hotspot: JDK-8221479: [s390] Fix JFR profiling JDK-8226515: AArch64: float point register corruption in ZBarrierSetAssembler::load_at JDK-8224880: AArch64: java/javac error with AllocatePrefetchDistance JDK-8219814: Help-info for pns(...) on Linux/mips lost JDK-8223186: HotSpot compile warnings from GCC 9 JDK-8219583: Windows build failure after JDK-8214777 (Avoid some GCC 8.X strncpy() errors in HotSpot) hotspot/compiler: JDK-8219335: "failed: unexpected type" assert failure in ConnectionGraph::split_unique_types() with unsafe accesses JDK-8224672: (lib)hsdis-.so search incorrect after JDK-8213084 JDK-8224652: 32-bit build failures after JDK-8213084 (Rework and enhance Print[Opto]Assembly output) JDK-8218601: [AOT] Crash in AOTCodeHeap::mark_evol_dependent_methods JDK-8223262: [AOT] jaotc crashes with assert(!(((ThreadShadow*)__the_thread__)->has_pending_exception())) failed: Should not allocate with exception pending JDK-8218169: [AOT] Segmentation fault when running java with AOTed Graal in -Xcomp mode on windows JDK-8217466: [BACKOUT] Optimize CodeHeap Analytics JDK-8225064: [Graal] Application SEGV in G1ParScanThreadState::copy_to_survivor_space(G1HeapRegionAttr, oopDesc*, markOopDesc*)+0x48 JDK-8223422: [Graal] assert(!m->can_be_statically_bound(InstanceKlass::cast(ctxk))) failed: redundant JDK-8223531: [Graal] assert(type() == T_INT) failed: type check JDK-8225199: [Graal] compiler/jvmci/compilerToVM/IsMatureVsReprofileTest.java fails with -XX:CompileThresholdScaling=0.1 JDK-8220627: [Graal] Enable java/util/Base64$Encoder.encodeBlock([BII[BIZ)V stub JDK-8217758: [Graal] Graal should retain local variables if jvmti can_pop_frame/can_access_local_variables capability is set JDK-8221577: [Graal] Implement basic type consistency checks for Low level MH intrinsics JDK-8221514: [Graal] java/lang/String/CompactString/ tests fail with "GraalError: failed guarantee: no FrameState at DeoptimizingNode" in Graal -Xcomp mode JDK-8221782: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.jdk.vm.ci.services JDK-8215687: [Graal] unit test CheckGraalIntrinsics failed after 8212043 JDK-8217848: [Graal] vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003/TestDescription.java fails JDK-8226778: [JVMCI] Handle unpacking properly in Deoptimiziation::get_cached_box() JDK-8217445: [JVMCI] incorrect management of JVMCI compilation failure reason string JDK-8226566: [JVMCI] java.* classes are no longer necessarily resolved by the boot class loader JDK-8223639: [JVMCI] jvmciCompiler.cpp needs to include "oops/objArrayOop.inline.hpp"" JDK-8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library JDK-8209626: [JVMCI] Use implicit exception table for dispatch and printing JDK-8217459: [PPC64] Cleanup non-vector version of CRC32 JDK-8224090: [PPC64] Fix SLP patterns for filling an array with double float literals JDK-8216060: [PPC64] Vector CRC implementation should be used by interpreter and be faster for short arrays JDK-8221083: [ppc64] Wrong oop compare in C1-generated code JDK-8217465: [REDO] - Optimize CodeHeap Analytics JDK-8173196: [REDO] C2 does not optimize redundant memory operations with G1 JDK-8222271: [s390] optimize register usage in C2 instruction forms for clearing arrays JDK-8223645: AArch64 build broken by fix for 8223136 JDK-8212043: AArch64: Add floating-point Math.min/max intrinsics JDK-8222785: aarch64: add necessary masking for immediate shift counts JDK-8221658: aarch64: add necessary predicate for ubfx patterns JDK-8214922: Aarch64: Add vectorization support for fmin/fmax JDK-8217368: AArch64: C2 recursive stack locking optimisation not triggered JDK-8219993: AArch64: Compiled CI stubs are unsafely modified JDK-8223020: aarch64: expand minI_rReg and maxI_rReg patterns into separate instructions JDK-8224671: AArch64: mauve System.arraycopy test failure JDK-8216350: AArch64: monitor unlock fast path not called JDK-8222412: AARCH64: multiple instructions encoding issues JDK-8221995: AARCH64: problems with CAS instructions encoding JDK-8219006: AArch64: Register corruption in slow subtype check JDK-8218966: AArch64: String.compareTo() can read memory after string JDK-8215792: AArch64: String.indexOf generates incorrect result JDK-8216259: AArch64: Vectorize Adler32 intrinsics JDK-8217869: Add count_leading_zeros utility JDK-8225202: Add missing include after JDK-8223320 JDK-8218550: Add test omitted from JDK-8212043 JDK-8163511: Allocation of compile task fails with assert: "Leaking compilation tasks?" JDK-8222825: ARM32 SIGILL issue on single core CPU (not supported PLDW instruction) JDK-8220656: ARM32: -XX:MaxVectorSize=16 makes SIGILL JDK-8224648: assert(!exceeding_node_budget()) failed: Too many NODES required! failure with ctw JDK-8219520: assert(Compile::current()->live_nodes() < Compile::current()->max_node_limit()) failed: Live Node limit exceeded limit JDK-8219517: assert(false) failed: infinite loop in PhaseIterGVN::optimize JDK-8224162: assert(profile.count() == 0) failed: sanity in InlineTree::is_not_reached JDK-8226627: assert(t->singleton()) failed: must be a constant JDK-8075052: Autobox elimination hinders loop unrolling JDK-8223363: Bad node estimate assertion failure JDK-8216200: BCEscapeAnalyzer::ArgumentMap::set_intersect() is incorrect JDK-8225141: Better handling of classes in error state by fast class initialization checks JDK-8219951: Build failure on Mac and Windows after JDK-8219922 JDK-8218721: C1's CEE optimization produces safepoint poll with invalid debug information JDK-8218406: C1: Redundant nmethod dependency for private method is added JDK-8214352: C1: Unnecessary "compilation bailout: block join failed" with JVMTI JDK-8221592: C2 compilation failed with assert(!q->is_MergeMem()) JDK-8224539: C2 compilation fails during ArrayCopyNode optimizations with assert(i < _max) failed: oob: i=1, _max=1 JDK-8229219: C2 compilation fails with assert: Bad graph detected in build_loop_late JDK-8220714: C2 Compilation failure when accessing off-heap memory using Unsafe JDK-8219807: C2 crash in IfNode::up_one_dom(Node*, bool) JDK-8217990: C2 UseOptoBiasInlining: load of markword optimized to 0 if running with -XX:-EliminateLocks JDK-8217918: C2: -XX:+AggressiveUnboxing is broken JDK-8161334: C2: Cast nodes hinder memory alias analysis JDK-8218163: C2: Continuous deoptimization w/ Reason_speculate_class_check and Action_none JDK-8087128: C2: Disallow definition split on MachCopySpill nodes JDK-8217919: C2: Enable -XX:+AggressiveUnboxing by default JDK-8059241: C2: Excessive RemoveUseless passes during incremental inlining JDK-8192001: C2: inlining through dispatching MH linkers ignores speculative type of the receiver JDK-8191998: C2: inlining through MH linkers drops speculative part of argument types JDK-8220374: C2: LoopStripMining doesn't strip as expected JDK-8219902: C2: MemNode::can_see_stored_value() ignores casts which carry control dependency JDK-8217760: C2: Missing symbolic info on a call from intrinsics when invoked through MethodHandle JDK-8157372: C2: Node::cmp() should return bool JDK-8188133: C2: Static field accesses in clinit can trigger deoptimizations JDK-8218881: C2: StaticFinalFieldPrinter doesn't handle T_ARRAY values in T_OBJECT fields JDK-8202952: C2: Unexpected dead nodes after matching JDK-8223216: C2: Unify class initialization checks between new, getstatic, and putstatic JDK-8218874: C2: Unsafe to access PhaseIdealLoop outside of constructors JDK-8216154: C4819 warnings at HotSpot sources on Windows JDK-8216989: CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does not check for zero length on AARCH64 JDK-6986483: CHA: optimize calls through interfaces JDK-8223141: Change (count) suffix _ct into _cnt. JDK-8216987: ciMethodData::load_data() unpacks MDOs with non-atomic copy JDK-8219642: ciReplay loads wrong data when MethodData size changes JDK-8225106: Class initialization checks assert when holder klass is in error state JDK-8220341: Class redefinition fails with assert(!is_unloaded()) failed: unloaded method on the stack JDK-8221541: clean up functions in CompilerOracle JDK-8223140: Clean-up in 'ok_to_convert()' JDK-8223142: Clean-up WS and CB. JDK-8225509: clean_catch_blocks must add preds first JDK-8220420: Cleanup c1_LinearScan JDK-8223617: code_size2 needs adjustments JDK-8223770: code_size2 still too small in some compressed oops configurations JDK-8217922: Compiler dead code removal JDK-8224234: compiler/codegen/TestCharVect2.java fails in test_mulc JDK-8224254: compiler/graalunit/HotspotJdk9Test.java is timing out intermittently JDK-8223539: compiler/graalunit/HotspotTest.java hotspot.test.CheckGraalIntrinsics AssertionError: found plugins for intrinsics characterized as toBeInvestigated JDK-8226646: CTW of SPECjvm2008 hangs on windows-x64-debug JDK-8221853: Data race in compile broker (set_last_compile) JDK-8216360: Deprecate -XX:CompilationPolicyChoice JDK-8217447: Develop flag TraceICs is broken JDK-8228710: Disable AggressiveUnboxing until JDK-8224957 is fixed JDK-8223911: Disable bad node budget verification until the fix JDK-8224931: disable JAOTC invokedynamic support until 8223533 is fixed JDK-8223450: Disable Shenandoah C2 barriers verification for x86_32 JDK-8222074: Enhance auto vectorization for x86 JDK-8227112: exclude compiler/intrinsics/sha/sanity tests from AOT runs JDK-8217291: Failure of ::realloc() should be handled correctly in adlc/forms.cpp JDK-8218201: Failures when vmIntrinsics::_getClass is not inlined JDK-8216595: Fix broken builds after JDK-8216424 JDK-8218544: Fix build on windows: missing include JDK-8216580: Fix generation of VNNI vector code by allowing adjacent LoadS nodes to be isomorphic JDK-8224558: Fix replicateB encoding JDK-8219687: G1 asserts nmethod should not be unloaded during parallel code cache unloading JDK-8227034: Graal crash with gcbasher JDK-8211100: hotspot C1 issue with comparing long numbers on x86 32-bit JDK-8223885: hs_err and replay file may contain garbage when overwriting existing file JDK-8217564: idempotent protection missing in crc32c.h JDK-8225110: IGV build definition uses non-secure transport JDK-8224826: Implement fast class initialization checks on PPC64 JDK-8224827: Implement fast class initialization checks on s390 JDK-8223213: Implement fast class initialization checks on x86-64 JDK-8219011: Implement MacroAssembler::warn method on AArch64 JDK-8220501: Improve c1_ValueStack locks handling JDK-8223444: Improve CodeHeap Free Space Management JDK-8223504: improve performance of forall loops by better inlining of "iterator()" methods. JDK-8217519: Improve RegMask population count calculation JDK-8217371: Incorrect LP64 guard in x86.ad after JDK-8210764 (Update avx512 implementation) JDK-8220502: Inefficient pre-sizing of PhiResolverState arrays in c1_LIRGenerator JDK-8219214: Infinite Loop in CodeSection::dump() JDK-8218700: infinite loop in HotSpotJVMCIMetaAccessContext.fromClass after OutOfMemoryError JDK-8221482: Initialize VMRegImpl::regName[] earlier to prevent assert during PrintStubCode JDK-8224742: JLONG_FORMAT_W incompatible with type jlong JDK-8227260: JNI upcalls should bypass class initialization barrier in c2i adapter JDK-8228340: JVMCI deleteGlobalHandle doesn't delete the handle JDK-8226533: JVMCI: findUniqueConcreteMethod should handle statically bindable methods directly JDK-8223050: JVMCI: findUniqueConcreteMethod() should not use Dependencies::find_unique_concrete_method() for non-virtual methods JDK-8223796: JVMCIEnv::get_jvmci_type does not keep klasses alive JDK-8219403: JVMCIRuntime::adjust_comp_level should be replaced JDK-8218879: Keep track of memory accesses originated from Unsafe JDK-8224675: Late GC barrier insertion for ZGC JDK-8218468: Load barrier slow path node should be MachTypeNode JDK-8224538: LoadBarrierNode::common_barrier must check address JDK-8216199: Local variable arg defined but never used in BCEscapeAnalyzer::compute_escape_for_intrinsic() JDK-8219664: LogCompilation: java.lang.Error: Unexpected method mismatch during late inlining JDK-8196347: LogCompilation: generate log file on the fly for input to junits JDK-8220198: Lots of com/sun/crypto/provider/Cipher tests fail on x86_32 due to missing SHA512 stubs JDK-8218937: Make mlvmJvmtiUtils strncpy uses GCC 8.x friendly JDK-8226287: Make process_users_of_allocation handle gc barriers JDK-8217909: Make unused r12 register (without compressed oops) available to regalloc in C2 JDK-8224580: Matcher can cause oop field/array element to be reloaded JDK-8224568: minimal and zero build fails after JDK-8213084 JDK-8217639: Minimal and Zero builds fail after JDK-8217519 (Improve RegMask population count calculation) JDK-8215551: Missing case label in nmethod::reloc_string_for() JDK-8219486: Missing reg_mask_init() breaks x86_32 build JDK-8223621: Move Universe usage out of oopRecorder.hpp JDK-8224674: NMethod state machine is not monotonic JDK-8221456: nmethod::make_unloaded() clears _method member too early JDK-8218776: no man page for jaotc JDK-8225475: Node budget asserts on x86_32/64 JDK-8223502: Node estimate for loop unswitching is not correct: assert(delta <= 2 * required) failed: Bad node estimate JDK-8216608: Obsolete stale compiler flags JDK-8217383: Obsolete UseImplicitStableValues JDK-8215483: Off heap memory accesses should be vectorized JDK-8217250: Optimize CodeHeap Analytics JDK-8220159: Optimize various RegMask operations by introducing watermarks JDK-8222670: pathological case of JIT recompilation and code cache bloat JDK-8219582: PPC: Crash after C1 checkcast patched and GC JDK-8209951: Problematic sparc intrinsic: com.sun.crypto.provider.CipherBlockChaining JDK-8223171: Redundant nmethod dependencies for effectively final methods JDK-8076988: reevaluate trivial method policy JDK-8217629: RegMask::find_lowest_bit can reuse count_trailing_zeros utility JDK-8225429: Regression in disassembly quality JDK-8217716: Remove dead code in PhaseChaitin JDK-8218625: Remove dead code in relocInfo JDK-8217387: Remove dead develop flag CIFireOOMAt JDK-8217266: Remove dead LIR_List::compare_to and LIR_Code::lir_compare_to JDK-8216262: Remove develop flag DelayCompilationDuringStartup JDK-8217388: Remove develop flag ProfilerPCTickThreshold JDK-8216359: Remove develop flags TraceCompilationPolicy and TimeCompilationPolicy JDK-8216423: Remove FillDelaySlots JDK-8219519: Remove linux_sparc.ad and linux_aarch64.ad JDK-8220411: Remove ScavengeRootsInCode=0 code JDK-8216424: Remove TimeLivenessAnalysis JDK-8225564: Remove wrong assert in clean_catch_blocks JDK-8223139: Rename mandatory policy-do routines. JDK-8223137: Rename predicate 'do_unroll_only()' to 'is_unroll_only()'. JDK-8213416: Replace some enums with static const members in hotspot/compiler JDK-8223143: Restructure/clean-up for 'loopexit_or_null()'. JDK-8216375: Revert JDK-8145579 after JDK-8076988 is resolved JDK-8220515: Revert removal of for_each_lock_value JDK-8213084: Rework and enhance Print[Opto]Assembly output JDK-8219919: RuntimeStub's name lost with PrintFrameConverterAssembly JDK-8218991: s390: Add intrinsic for GHASH algorithm JDK-8228618: s390: c1/c2 fail to add a metadata relocation in the static call stub. JDK-8224496: Shenandoah compilation fails with assert(is_CountedLoopEnd()) failed: invalid node class JDK-8223389: Shenandoah optimizations fail with assert(!phase->exceeding_node_budget()) JDK-8217874: Shenandoah: AArch64: Clobbered register in ShenandoahBarrierSetAssembler::cmpxchg_oop() JDK-8222738: Shenandoah: assert(is_Proj()) failed when running cometd benchmarks JDK-8219922: Simplify IndexSetIterator::next using count_trailing_zeros JDK-8223138: Small clean-up in loop-tree support. JDK-8220211: Small update to Fix generation of VNNI vector code by allowing adjacent LoadS nodes to be isomorphic (JDK-8216580) JDK-8217782: Spill detection broken after JDK-8217716 JDK-8219448: split-if update_uses accesses stale idom data JDK-8217407: StackValue::print_on() crashes on NULL handle JDK-8223537: testlibrary_tests/ctw/ClassesListTest.java fails with Agent timeout frequently JDK-8216556: Unnecessary liveness computation with JVMTI JDK-8226905: unproblem list applications/ctw/modules/* tests on windows JDK-8224658: Unsafe access C2 compile fails with assert(flat != TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr: adr_type = NULL JDK-8202414: Unsafe write after primitive array creation may result in array length change JDK-8221598: Update Graal JDK-8223332: Update JVMCI JDK-8225450: use @file in CtwRunner JDK-8226198: use of & instead of && in LibraryCallKit::arraycopy_restore_alloc_state JDK-8222371: Use UL for TraceNMethodInstalls code JDK-8227222: vmTestbase/jit/FloatingPoint/gen_math/Loops04/Loops04.java hits assert(((!attributes->uses_vl()) || (attributes->get_vector_len() == AVX_512bit) || (!_legacy_mode_vl) || (attributes->is_legacy_mode()))) failed: XMM register should be 0-15 JDK-8225567: Wrong file headers with 8202414 fix changeset JDK-8217561: X86: Add floating-point Math.min/max intrinsics JDK-8221343: x86_32 crashes on startup with "_hwm out of range" JDK-8222032: x86_32 fails with "wrong size of mach node" on AVX-512 machine JDK-8222397: x86_32 tests with UseSHA1Intrinsics SEGV due to garbled registers JDK-8218031: Zero broken after JDK-8217922 (Compiler dead code removal) JDK-8227407: ZGC: C2 loads and load barriers can get separated by safepoints JDK-8216372: ZGC: Put C2 load barrier stub routines in separate codeblobs JDK-8221542: ~15% performance degradation due to less optimized inline decision hotspot/gc: JDK-8188066: (ref) Examine the reachability of JNI WeakGlobalRef and interaction with phantom refs JDK-8225104: 32-bit build failures after JDK-8222252 JDK-8214527: AArch64: ZGC for Aarch64 JDK-8222105: Add "use_" prefix to G1Policy::adaptive_young_list_length JDK-8222145: Add -XX:SoftMaxHeapSize flag JDK-8219748: Add and use getter for the timing object in G1 JDK-8223822: Add gc IDs in the log of gc verification JDK-8221913: Add GC.selected() jtreg-ext function JDK-8219816: Add IsArray/RemoveExtent type traits utilities JDK-8223392: Add missing BitMap comments for JDK-8222986 JDK-8219369: Add named constants for iterating ExtRootScan phases JDK-8219573: Add NMethodClosure JDK-8214799: Add package declaration to each JTREG test case in the gc folder JDK-8222986: Add parameter to skip clearing CHeapBitMaps when resizing JDK-8224247: AllocateOldGenAt fires assertion failure JDK-8221102: Allow GC threads to participate in threads claiming protocol JDK-8218672: AOT code root scanning shows in the wrong position in the logs JDK-8223675: arm32 build failure after 8223136 (Move compressed oops functions to CompressedOops class) JDK-8217399: Backout 8217358 JDK-8224836: Backout: JDK-8224626: Shenandoah: Elide barriers on uncommon traps JDK-8218975: Bug in macOSX kernel's pthread support JDK-8217342: Build failed with excluding JFR JDK-8221763: Build fails when using --with-jvm-features=-g1gc,-jfr,-shenandoahgc JDK-8223651: Build fails with --with-jvm-features=-jfr and --disable-precompiled-headers JDK-8221363: Build failure after JDK-8220240 (Refactor shared dirty card queue) JDK-8223583: Build failure after JDK-8223567 (Rename ShenandoahBrooksPointer to ShenandoahForwarding) JDK-8220344: Build failures when using --with-jvm-features=-g1gc,-jfr JDK-8217576: C1 atomic access handlers use incorrect decorators JDK-8219557: Change task definitions to not include RunThese for ZGC JDK-8221394: Clean up ConcurrentGCThread JDK-8218668: Clean up evacuation of optional collection set JDK-8223624: Cleanup includes of universe.hpp JDK-8217319: Cleanup Shenandoah includes JDK-8225441: Cleanup ShenandoahHeap::atomic_compare_exchange_oop JDK-8220609: Cleanups in ScavengableNMethods JDK-8222086: CodeCache::UnloadingScope needs to preserve and restore previous IsUnloadingBehavior JDK-8217417: Decorator name typo: C2_TIGHLY_COUPLED_ALLOC JDK-8221359: Eliminate filter_thread_buffers JDK-8216285: Enable inlining of CollectedHeap::obj-/array-/class_allocate JDK-8217014: Epsilon should not ignore Metadata GC causes JDK-8226366: Excessive ServiceThread wakeups for OopStorage cleanup JDK-8222333: fastdebug build broken after JDK-8221393 (phase_mapping[] doesn't match enum Phase in WeakProcessorPhases) JDK-8223637: Fix build breakage after 8223136 JDK-8223267: Fix incorrect usage of GCTraceTime in g1FullCollector and g1CollectedHeap JDK-8215114: Fix indent and dead code in GCPolicyCounters JDK-8224038: Fix remaining InCSetState mentions JDK-8223244: Fix usage of ARRAYCOPY_DISJOINT decorator JDK-8224573: Fix windows build after JDK-8221507 JDK-8218974: Free GC native structures in nmethod::flush JDK-8218680: G1 crashes during calculation of old collection set candidates JDK-8218880: G1 crashes when issuing a periodic GC while the GCLocker is held JDK-8225716: G1 GC: Undefined behaviour in G1BlockOffsetTablePart::block_at_or_preceding JDK-8222492: G1 unnecessarily scans remembered set cards for regions that already have been evacuated JDK-8214946: G1: Initialize all class members on construction JDK-8225418: G1: region attribute remembered set state disagrees with actual remembered set state JDK-8221517: G1: Reserved page size for heap can be wrong JDK-8219976: GarbageCollectionNotificationInfo always says "No GC" when running Shenandoah JDK-8223397: gc+promotion log lines are missing the GC id JDK-8220290: gc_epilogue(full = false) is called on Full GC path after JDK-8215221 JDK-8214363: HeapWord should not be a fake class JDK-8221507: Implement JFR events for Shenandoah JDK-8222480: Implementation: JEP 351: ZGC: Uncommit Unused Memory JDK-8219100: Improve do_collection_pause_at_safepoint JDK-8223162: Improve ergonomics for Sparse PRT entry sizing JDK-8200545: Improve filter for enqueued deferred cards JDK-8220228: Improve Shenandoah pacing histogram message JDK-8222841: Incorrect static call stub interactions with class unloading JDK-8220388: Increase -inlinehint-threshold for Clang to avoid G1 pause time regression JDK-8220671: Initialization race for non-JavaThread PtrQueues JDK-8221260: Initialize more class members on construction, remove some unused ones JDK-8221732: Introduce CollectedHeap::hash_oop() JDK-8222462: Introduce CollectedHeap::unused() JDK-8213229: Investigate treating StringTable as weak in young collections JDK-8222252: Java ergonomics limits heap to 128GB with disabled compressed oops JDK-8218060: JDK-8217786 breaks build due to remaining unused function JDK-8218063: JDK-8218060 breaks build for S390 JDK-8220347: JEP 351: ZGC: Uncommit Unused Memory (Experimental) JDK-8212630: jtreg/gc/logging/TestMetaSpaceLog.java failed with Agent timed out JDK-8217385: JTREG: Clean up, make sure to close resources JDK-8217329: JTREG: Clean up, remove unused imports in gc folder JDK-8217389: JTREG: Clean up, remove unused variable warnings JDK-8217332: JTREG: Clean up, use generics instead of raw types JDK-8221766: Load-reference barriers for Shenandoah JDK-8220610: Make CollectedHeap nmethod functions pure virtual JDK-8216258: Make FreeIdSet semaphore-based JDK-8225478: Make G1CMRootRegions independent of HeapRegions JDK-8219098: Make output of region strings more regular in error messages JDK-8212826: Make PtrQueue free list lock-free JDK-8214201: Make PtrQueueSet completed buffer list private JDK-8223693: Memory wastage in size of per-region type buffers in GC JDK-8219096: Merge print_termination_stats code with current logging JDK-8217432: MetaspaceGC::_capacity_until_GC exceeds MaxMetaspaceSize JDK-8223676: Minimal VM build failure after 8223136 (Move compressed oops functions to CompressedOops class) JDK-8217522: Missing barriers in some java_lang_String assertion code after JDK-8217442 JDK-8217794: Missing termination check results violation of termination invariant JDK-8219097: Move comment about using weak code blobs closure for code root scanning to correct place JDK-8223136: Move compressed oops functions to CompressedOops class JDK-8224160: Move G1RemSetScanClosure into g1RemSet.cpp file JDK-8223620: Move IsGCActiveMark implementation out of header JDK-8223623: Move oopFactory function definitions out of oopFactory.hpp JDK-8220606: Move ScavengableNMethods unlinking to unregister_nmethod JDK-8220343: Move scavenge_root_nmethods from shared code JDK-8223622: Move Universe usage out of memAllocator.hpp JDK-8223619: Move VerifyOption out of Universe JDK-8213827: NUMA heap allocation does not respect process membind/interleave settings JDK-8217358: Optimized build is broken by Shenandoah changes JDK-8217785: Padding ParallelTaskTerminator::_offered_termination variable JDK-8222843: Print Shenandoah cset map addresses in hs_err JDK-8221688: Quarantine Shenandoah string dedup tests JDK-8221392: Reduce ConcurrentGCThreads spinning during start up JDK-8212206: Refactor AdaptiveSizePolicy to separate out code related to GC overhead JDK-8224187: Refactor arraycopy_prologue to allow ZGC read barriers on arraycopy JDK-8221509: Refactor assert( G1CollectedHeap::used() == recalculate_used() ) with better message JDK-8224167: Refactor PtrQueue completed buffer processing JDK-8220240: Refactor shared dirty card queue JDK-8220350: Refactor ShenandoahHeap::initialize JDK-8221648: Remove CollectedHeap::is_in_closed_subset() JDK-8198505: Remove CollectorPolicy and its subclasses JDK-8218192: Remove copy constructor for MemRegion JDK-8219747: Remove g1_ prefix to g1_remset and g1_policy members in G1CollectedHeap JDK-8215299: Remove G1CMTask::should_exit_termination()'s undesirable side-effect JDK-8220301: Remove jbyte use in CardTable JDK-8225171: Remove leftovers in shenandoahBarrierSetC1.cpp JDK-8221558: Remove obsolete uses of OopStorage::ParState _par_state JDK-8216072: Remove TaskTerminator's assignment operator JDK-8219817: Remove unused CollectedHeap::block_size() JDK-8221748: Remove unused oopDesc::is_unlocked_oop() JDK-8217474: Remove WhiteBox.getConcurrentGCPhases() JDK-8217328: Rename CollectionSetChooser to G1CollectionSetChooser JDK-8218089: Rename DirtyCardQueue et al to follow usual G1 naming conventions JDK-8217374: Rename G1 EvacuationInfo class to G1EvacuationInfo JDK-8223018: Rename G1RemSet::*oops_into_collection_set_do methods JDK-8215492: Rename INTERNAL_EMPTY to something less "internal" JDK-8223567: Rename ShenandoahBrooksPointer to ShenandoahForwarding JDK-8224579: ResourceMark not declared in shenandoahRootProcessor.inline.hpp with --disable-precompiled-headers JDK-8225357: Rewire ShenandoahHeap::maybe_update_with_forwarded for contending fixups JDK-8222664: runtime/appcds/sharedStrings/SharedStringsStress.java assert GC active during NoGCVerifier JDK-8218920: Scan HCC should be on the same level as Update RS etc. in the log JDK-8224531: SEGV while collecting Klass statistics JDK-8225014: Separate ShenandoahRootScanner method for object_iterate JDK-8215221: Serial GC misreports young GC time JDK-8223446: Shenandoah breaks alignment with some HumongousThreshold values JDK-8222926: Shenandoah build fails with --with-jvm-features=-compiler1 JDK-8217578: Shenandoah cleanup unused timings after concurrent string table change JDK-8217343: Shenandoah control thread should be able to run at critical priority JDK-8215549: Shenandoah deduplication cleans up table/queue twice JDK-8223448: Shenandoah disabled barriers blocks omit LRB JDK-8220161: Shenandoah does not need to initialize PLABs for safepoint workers JDK-8220153: Shenandoah does not work with TransparentHugePages properly JDK-8221735: Shenandoah fails ctw/modules/jdk_management_agent.java with Traversal JDK-8217419: Shenandoah fails to build after JDK-8212826 (Make PtrQueue free list lock-free) JDK-8223767: Shenandoah fails to build on Solaris x86_64 JDK-8219857: Shenandoah GC may initialize thread's gclab twice JDK-8222786: Shenandoah get_barrier_strength should accept all shapes of (Weak)CAS reference barriers JDK-8225046: Shenandoah metrics logs refactoring JDK-8219524: Shenandoah misreports "committed" size in MemoryMXBean JDK-8223570: Shenandoah needs to acquire lock before CLDG::clear_claimed_marks JDK-8220546: Shenandoah Reports timing details for weak root processing JDK-8223759: Shenandoah should allow arbitrarily low initial heap size JDK-8224522: Shenandoah should apply barriers on deoptimization JDK-8220162: Shenandoah should not commit HugeTLBFS memory JDK-8221278: Shenandoah should not enqueue string dedup candidates during root scan JDK-8221435: Shenandoah should not mark through weak roots JDK-8222186: Shenandoah should not uncommit below minimum heap size JDK-8222185: Shenandoah should report "committed" as capacity JDK-8220444: Shenandoah should use parallel version of WeakProcessor in root processor for weak roots JDK-8222130: Shenandoah should verify roots after pre-evacuation JDK-8225048: Shenandoah x86_32 support JDK-8222188: Shenandoah: Adjust Shenandoah work gang types JDK-8224978: Shenandoah: Allows root verifier to verify some roots outside safepoints with proper locks JDK-8221848: Shenandoah: ArrayCopy post-barrier improvements JDK-8221629: Shenandoah: Cleanup class unloading logic JDK-8225341: Shenandoah: CM::update_thread_roots() needs to handle derived pointers JDK-8222125: Shenandoah: Crash when running with ShenandoahParallelSafepointThreads=1 JDK-8224179: Shenandoah: CTW test failures with traversal GC JDK-8224495: Shenandoah: Do not rescan code roots in final mark pause if it is not degenerated GC JDK-8224626: Shenandoah: Elide barriers on uncommon traps JDK-8224584: Shenandoah: Eliminate forwarding pointer word JDK-8224115: Shenandoah: Eliminate RWLock that protects recorded nmethod data array JDK-8224525: Shenandoah: Eliminate shenandoah verifier's side-effects JDK-8221750: Shenandoah: Enable ThreadLocalHandshake by default JDK-8222227: Shenandoah: Fix Traversal GC weak roots handling in final-traversal pause JDK-8221751: Shenandoah: Improve SATB enqueueing JDK-8216973: Shenandoah: Kick up cleanup phases in the right places JDK-8224679: Shenandoah: Make ShenandoahParallelCodeCacheIterator noncopyable JDK-8222129: Shenandoah: Missing CompareAndSwapP/N case in get_barrier_strength() JDK-8223184: Shenandoah: Missing roots in SRP::process_all_roots_slow JDK-8222425: Shenandoah: Move commonly used closures to separate files JDK-8225572: Shenandoah: Move JNIHandles root out of serial roots JDK-8224508: Shenandoah: Need to update thread roots in final mark for piggyback ref update cycle JDK-8223951: Shenandoah: Only need to update thread roots during final update refs JDK-8223762: Shenandoah: overflows in calculations involving heap capacity JDK-8224875: Shenandoah: ParallelCleaning code unloading should take lock to protect shared code roots array JDK-8224667: Shenandoah: Post-LRB cleanup JDK-8222992: Shenandoah: Pre-evacuate all roots JDK-8222259: Shenandoah: Pre-evacuate string-dedup roots in Traversal GC JDK-8223980: Shenandoah: Refactor and fix ObjArrayChunkedTask verification JDK-8223774: Shenandoah: Refactor ShenandoahRootProcessor and family JDK-8224210: Shenandoah: Refactor ShenandoahRootScanner to support scanning CSet codecache roots JDK-8224043: Shenandoah: Remove clear_claimed_marks() from start of concurrent_traversal() JDK-8222403: Shenandoah: Remove ShenandoahAlwaysTrueClosure, use AlwaysTrueClosure instead JDK-8222490: Shenandoah: Remove unused _par_state_string in ShenandoahRootEvacuator JDK-8222419: Shenandoah: Remove unused _par_state_string in ShenandoahRootProcessor JDK-8224932: Shenandoah: Rename ShenandoahHeapLock, make it general purpose lock JDK-8203232: Shenandoah: Resolve oops in SATB filter JDK-8222838: Shenandoah: SEGV on accessing cset bitmap for NULL ptr JDK-8224751: Shenandoah: Shenandoah Verifier should select proper roots according to current GC cycle JDK-8225514: Shenandoah: ShenandoahCodeRoots should inherit from AllStatic JDK-8223258: Shenandoah: SRP::process_all_roots_slow processes JvmtiExport weak oops twice JDK-8217016: Shenandoah: Streamline generation of CAS barriers JDK-8223215: Shenandoah: Support verifying subset of roots JDK-8224881: Shenandoah: trashing "Collection Set, Pinned" region during Degenerated GC JDK-8225229: Shenandoah: trim down default number of GC threads JDK-8225342: Shenandoah: use COMPILER2_OR_JVMCI macro consistently JDK-8220780: ShenandoahBS::AccessBarrier::oop_store_in_heap ignores AS_NO_KEEPALIVE JDK-8224970: ShenandoahRootScanner::roots_do assert is too strong JDK-8217213: shenandoahTaskQueue.hpp includes .inline.hpp file JDK-8220664: Simplify ShenandoahUpdateHeapRefsClosure JDK-8217203: Some more includes to .inline.hpp files in gc header files JDK-8219856: Spell out G1CollectorPolicy::is_hetero_heap JDK-8217330: Split G1CollectionSetChooser into collection set candidate container and the chooser algorithm JDK-8160539: Stack frame scanning acquires DerivedPointerTableGC_lock mutex JDK-8217778: StringTable cleanup miscalculates amount of dead objects JDK-8214236: sun.gc.collector.2.name should be changed JDK-8218049: Survivor MemoryMXBean used() size granularity is region based JDK-8215047: Task terminators do not complete termination in consistent state JDK-8226302: Test failures on IBM platforms (power and s/390) after JDK-8223837 JDK-8219232: Unit of concurrent active time logging is wrong JDK-8223449: Unprotected UseCompressedOops block in gc/shenandoah/shenandoahBarrierSetC1_x86.cpp JDK-8221875: Unquarantine Shenandoah string dedup tests JDK-8220345: Use appropriate type for G1RemSetScanState::IsDirtyRegionState JDK-8219613: Use NonJavaThread PtrQueues JDK-8217423: Windows gtest build fails after JDK-8212826 (Make PtrQueue free list lock-free) JDK-8220294: ZGC fails to build on GCC 4.4.7: Type parameter issue JDK-8225340: ZGC: Add logging of High Usage rule JDK-8225227: ZGC: Be exact in what load barrier to use in ZHeapIterator JDK-8217856: ZGC: Break out C2 matching rules into separate AD file JDK-8220587: ZGC: Break out forwarding information from ZPage JDK-8227083: ZGC: C2: Generates on_weak barrier for WeakCompareAndSwap JDK-8225770: ZGC: C2: Generates on_weak instead of on_strong barriers JDK-8217858: ZGC: Clean up ZDriver JDK-8221984: ZGC: Clean up ZOop JDK-8217855: ZGC: Clean up ZReferenceProcessor JDK-8221212: ZGC: Command-line flags should be marked experimental JDK-8220597: ZGC: Convert ZForwarding to use ZAttachedArray JDK-8220596: ZGC: Convert ZNMethodData to use ZAttachedArray JDK-8220588: ZGC: Convert ZRelocationSet to hold ZForwardings instead of ZPages JDK-8225642: ZGC: Crash due to bad oops being spilled to stack in load barriers JDK-8220601: ZGC: Delete ZNMethodTableEntry arrays using ZSafeDelete JDK-8220600: ZGC: Delete ZPages using ZSafeDelete JDK-8218767: ZGC: Do not assume that r12 is a special register in C2 JDK-8220591: ZGC: Don't delay reclaimation of ZVirtualMemory JDK-8224966: ZGC: Don't skip oop verification in OopMapSet::all_do() JDK-8219466: ZGC: Extract allocation functionality into a new ZNMethodAllocator class JDK-8219469: ZGC: Extract functions out from ZNMethodTable into new ZNMethod class JDK-8219468: ZGC: Extract iteration functionality into a new ZNMethodTableIteration class JDK-8217503: ZGC: Fix fall through bug in ZBarrierSetC2::escape_add_final_edges() JDK-8221537: ZGC: Fix incorrect comment in zNMethod table entry layout JDK-8223016: ZGC: Fix misaligned statistics printout JDK-8219638: ZGC: Free ZNMethodDataOops under a lock JDK-8220704: ZGC: gc tests complain Java heap too small JDK-8222469: ZGC: Generalize ZPageCache::flush() JDK-8221153: ZGC: Heap iteration and verification pollutes GC statistics JDK-8219332: ZGC: Improve ZRootsIteratorClosure abstraction JDK-8221786: ZGC: Increase max heap size to 16TB JDK-8224185: ZGC: Introduce "High Usage" rule JDK-8220595: ZGC: Introduce ZAttachedArray JDK-8220599: ZGC: Introduce ZSafeDelete JDK-8222467: ZGC: Log min/max/softmax capacity JDK-8219718: ZGC: Make nmethod entry barriers and nmethod::is_unloading use ZNMethodDataOops JDK-8217258: ZGC: Minor cleanup of ZBarrierSetAssembler JDK-8217257: ZGC: Minor cleanup of ZBarrierSetC2 JDK-8217747: ZGC: Minor optimization of ZLoadBarrierStubC1 JDK-8220741: ZGC: Move CPU agnostic files from linux_x86 to linux JDK-8220592: ZGC: Move destruction of detached ZPages into ZPageAllocator JDK-8219464: ZGC: Move nmethod oop properties from ZNMethodTableEntry to ZNMethodData JDK-8220586: ZGC: Move relocation logic from ZPage to ZRelocate JDK-8217857: ZGC: Move SvcGCMarker to ZServiceabilityTracer JDK-8219467: ZGC: Move ZNMethodData to its own file JDK-8221540: ZGC: Reduce width of zForwardingEntry::from_index field JDK-8219463: ZGC: Remove redundant ZNMethodTable::_iter_lock JDK-8220594: ZGC: Remove superfluous ZPage::is_active() JDK-8220593: ZGC: Remove superfluous ZPage::is_detached() JDK-8220589: ZGC: Remove superfluous ZPageTableEntry JDK-8223308: ZGC: Remove ZGranuleMap::size() JDK-8220590: ZGC: Remove ZPages from ZPageTable when freed JDK-8221219: ZGC: Remove ZStallOnOutOfMemory option JDK-8220569: ZGC: Rename and rework ZUnmapBadViews to ZVerifyViews JDK-8219634: ZGC: Rename ZAddressRangeMap to ZGranuleMap JDK-8219633: ZGC: Rename ZPageSizeMin to ZGranuleSize JDK-8221146: ZGC: Reports too much relocated JDK-8215985: ZGC: Simplify reference processing in light of JDK-8175797 JDK-8217745: ZGC: Simplify ZLoadBarrierStubC1 JDK-8224965: ZGC: Strengthen ZHeap::is_in() JDK-8224962: ZGC: Strengthen ZHeap::is_oop() JDK-8223961: ZGC: Unexpected behaviour due to ZMetronome::wait_for_tick() oversleeping JDK-8219331: ZGC: Unify TLAB retire/remap handling JDK-8222182: ZGC: Use SoftMaxHeapSize to guide GC heuristics JDK-8219462: ZGC: Use wait/notify in ZNMethodTable JDK-8222180: ZGC: ZForwarding::verify() failing when checking for duplicates JDK-8227175: ZGC: ZHeapIterator visits potentially dead objects hotspot/jfr: JDK-8216064: -XX:StartFlightRecording:settings= doesn't work properly JDK-8185525: Add JFR event for DictionarySizes JDK-8223438: add VirtualizationInformation JFR event JDK-8216283: Allow shorter method sampling interval than 10 ms JDK-8216995: Clean up JFR command line processing JDK-8220293: Deadlock in JFR string pool JDK-8224139: Deprecate -XX:FlightRecorder option JDK-8217362: Emergency dump does not work when disk=false is set JDK-8225310: JFR crashed in JfrPeriodicEventSet::requestProtectionDomainCacheTableStatistics() JDK-8219566: JFR did not collect call stacks when MaxJavaStackTraceDepth is set to zero JDK-8219205: JFR file without license header JDK-8225706: JFR RootResolver resets CLD claims with no restore JDK-8221569: JFR tool produces incorrect output when both --categories and --events are specified JDK-8220555: JFR tool shows potentially misleading message when it cannot access a file JDK-8220657: JFR.dump does not work when filename is set JDK-8217089: JFR: Lazy install os interface components for improved startup JDK-8214542: JFR: Old Object Sample event slow on a deep heap in debug builds JDK-8217647: JFR: recordings on 32-bit systems unreadable JDK-8227605: Kitchensink fails "assert((((klass)->trace_id() & (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed: invariant" JDK-8216436: last JFR recording might be empty JDK-8218935: Make jfr strncpy uses GCC 8.x friendly JDK-8223599: minimal build fails after JDK-8185525 JDK-8216486: Possibility of integer overflow in JfrThreadSampler::run() JDK-8214803: Provide SQE and Infra support for 8203359 - container aware JFR events JDK-8224217: RecordingInfo should use textual representation of path JDK-8228834: Regression caused by JDK-8214542 not installing complete checkpoint data to candidates JDK-8225004: Remove invalid assertion in jfr_conditional_flush() JDK-8216578: Remove unused/obsolete method in JFR code JDK-8215727: Restore JFR thread sampler loop to old / previous behavior JDK-8221632: Several corrections to java FlightRecorderOptions section JDK-8227011: Starting a JFR recording in response to JVMTI VMInit and / or Java agent premain corrupts memory JDK-8215771: The jfr tool should pretty print reference chains hotspot/jvmti: JDK-8223026: [BACKOUT] Typo in test/hotspot/jtreg/TEST.groups is causing test harness failures JDK-8217827: [Graal] Some vmTestbase/nsk/jvmti/ResourceExhausted tests failing JDK-8215951: AArch64: jtreg test vmTestbase/nsk/jvmti/PopFrame/popframe005 segfaults JDK-8223044: Add back exception checking in tests JDK-8201655: Add thread-enabled support for the Heap Sampling JDK-8217348: assert(thread->is_Java_thread()) failed: just checking JDK-8221183: Avoid code cache walk in MetadataOnStackMark JDK-8223718: Checks in check_slot_type_no_lvt() should be always executed JDK-8223177: Data race on JvmtiEnvBase::_tag_map in double-checked locking JDK-8181171: Deleting method for RedefineClasses breaks ResolvedMethodName JDK-8220512: Deoptimize redefinition functions that have dirty ICs JDK-8213501: Deploy ExceptionJniWrapper for a few tests JDK-8222935: Fix ExceptionCheckingJniEnv system JDK-8227277: HeapInspection::find_instances_at_safepoint walks dead objects JDK-8223441: HeapMonitorStatArrayCorrectnessTest fails due to sampling determinism JDK-8222072: JVMTI GenerateEvents() sends CompiledMethodLoad events to wrong jvmtiEnv JDK-8205126: JVMTI spec incorrectly states that PopFrame cannot be called on the current thread JDK-8046018: JVMTI Spec: can_redefine_any_class capability spec is inconsistent JDK-8223736: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails due to wrong number of MonitorContendedEntered events JDK-8226595: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java still fails due to wrong number of MonitorContendedEntered events JDK-8222934: mark new VM option AllowRedefinitionToAddOrDeleteMethods as deprecated JDK-8078725: method adjustments can be done just once for all classes involved into redefinition JDK-8215329: Modify ZGC requirement for HeapMonitorThreadTest.java JDK-8220628: Move the HeapMonitor library to C++ JDK-8212960: Normalize spaces around comparisons and ternary JDK-8218167: nsk/jvmti/scenarios/sampling/SP02/sp02t003 fails JDK-8211343: nsk_jvmti_parseoptions should handle multiple suboptions JDK-8216059: nsk_jvmti_parseoptions still has dependency on tilde separator JDK-8215716: PopFrame() was unexpectedly done JDK-8220342: Remove scavenge_root_nmethods_do from VM_HeapWalkOperation::collect_simple_roots JDK-8212824: Remove unnecessary spaces before/after comparison in vmTestbase JDK-8223227: Rename acquire_tag_map() to tag_map_acquire() in jvmtiEnvBase JDK-8192936: RI does not follow the JVMTI RedefineClasses spec that is too strict in the definition JDK-8215113: Sampling interval not always correct JDK-8139551: Scalability problem with redefinition - multiple code cache walks JDK-8221584: SIGSEGV in os::PlatformEvent::unpark() in JvmtiRawMonitor::raw_exit while posting method exit event JDK-8222952: Typo in test/hotspot/jtreg/TEST.groups is causing test harness failures JDK-8218812: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/TestDescription.java failed JDK-8215425: vmTestbase/nsk/jvmti/PopFrame should provide more detailed output JDK-8216386: vmTestbase/nsk/jvmti/PopFrame/popframe005/TestDescription.java fails JDK-8224555: vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001/TestDescription.java failed JDK-8218727: vmTestbase/nsk/jvmti/scenarios/events/EM04/em04t001/TestDescription.java crash in native library JDK-8222224: vmTestbase/nsk/jvmti/SingleStep/singlestep001/TestDescription.java fails JDK-8213001: vmTestbase/nsk/jvmti/ThreadStart/threadstart002/TestDescription.java debug agent times out JDK-8218401: WRONG_PHASE: vmTestbase/nsk/jvmti test crash hotspot/runtime: JDK-8218156: "jcmd VM.metaspace basic" misreports free chunk space JDK-8215398: -Xlog option usage => Invalid decorator '\temp\app_cds.log'. JDK-8215699: -Xlog::file cannot be used with named pipe JDK-8221685: -XX:BytecodeVerificationRemote and -XX:BytecodeVerificationLocal should be diagnostic options JDK-8219233: 3x performance drop for some Clojure applications JDK-8223248: [AIX] Remove old xlC 10 workaround for load acquire JDK-8226699: [BACKOUT] JDK-8221734 Deoptimize with handshakes JDK-8217338: [Containers] Improve systemd slice memory limit support JDK-8219565: [deadcode] remove share/utilities/intHisto.* JDK-8219798: [deadcode] remove src/hotspot/share/prims/evmCompat.cpp JDK-8217846: [Graal] vmTestbase/nsk/jdi/VirtualMachine/instanceCounts/instancecounts003/instancecounts003.java crash JDK-8221639: [i386] expand_exec_shield_cs_limit workaround is undefined code after JDK-8199717 JDK-8216559: [JFR] Native libraries not correctly parsed from /proc/self/maps JDK-8170639: [Linux] jsig is limited to a maximum of 64 signals JDK-8215707: [macosx] fix pthread_getschedparam and pthread_setschedparam calls JDK-8221539: [metaspace] Improve MetaspaceObj::is_metaspace_obj() and friends JDK-8220441: [PPC64] Clobber memory effect missing for memory barriers in atomics JDK-8213481: [REDO] Fix incorrect copy constructors in hotspot JDK-8223249: [s390] Cleanup TemplateInterpreterGenerator::generate_fixed_frame JDK-8216269: [s390] Debug build broken because CodeBlob has not been declared JDK-8225347: [s390] Unexpected exit from stack overflow test JDK-8220660: [s390]: debug build broken after JDK-8220301 JDK-8225178: [Solaris] os::signal() should call sigaction() with SA_SIGINFO JDK-8206107: [x86_32] jck tests for ldc2_w bytecode fail JDK-8219888: aarch64 : add CPU detection code for HiSilicon TSV110 JDK-8221725: AArch64 build failures after JDK-8221408 (Windows 32bit build build errors/warnings in hotspot) JDK-8222753: AArch64: Add CPU implementer code for Ampere JDK-8221220: AArch64: Add StoreStore membar explicitly for Volatile Writes in TemplateTable JDK-8228601: AArch64: Fix interpreter code at JVMCI deoptimization entry JDK-8219635: aarch64: missing LoadStore barrier in TemplateTable::fast_storefield JDK-8218185: aarch64: missing LoadStore barrier in TemplateTable::putfield_or_static JDK-8224828: aarch64: rflags is not correct after safepoint poll JDK-8220566: AArch64: Set default vm features for Ampere eMAG CPUs JDK-8219698: aarch64: SIGILL triggered when specifying unsupported hardware features JDK-8223534: add back fixed test_markOop.cpp JDK-8220774: Add HandshakeALot diag option JDK-8222090: Add Hygon Dhyana processor support JDK-8221325: Add information about swap space to print_memory_info() on MacOS JDK-8224221: add memprotect calls to event log JDK-8223574: add more thread-related system settings info to hs_error file on AIX JDK-8224958: add os::dll_load calls to event log JDK-8222713: Add OutputAnalyzer(Path) constructor JDK-8217450: Add PackageEntry::locked_lookup_only JDK-8216366: Add rationale to PER_CPU_SHARES define JDK-8212988: add recent class unloading events to the hs_err log JDK-8221535: add steal tick related information to hs_error file [linux] JDK-8220570: Additional trace when native thread creation fails JDK-8218276: AIX build fails in tieredThresholdPolicy.cpp JDK-8214235: arm32: assertion in collectedHeap.cpp: attempt to clean empty array JDK-8223336: Assert in VirtualMemoryTracker::remove_released_region when running the SharedArchiveConsistency.java test with -XX:NativeMemoryTracking=detail JDK-8220173: assert(_handle_mark_nesting > 1) failed: memory leak: allocating handle outside HandleMark JDK-8221437: assert(java_lang_invoke_ResolvedMethodName::vmtarget(resolved_method()) == m()) failed: Should not change after link resolution JDK-8220095: Assertion failure when symlink (with different name) is used for lib/modules file JDK-8216982: Assertion poison page established too early JDK-8218041: Assorted wrong/missing includes JDK-8224020: AsyncGetCallTrace test should not run on PPC64 or IA64 JDK-8220690: ATTRIBUTE_ALIGNED requires GNU extensions enabled JDK-8214777: Avoid some GCC 8.X strncpy() errors in HotSpot JDK-8221208: Backout JDK-8218446 JDK-8219969: Backout JDK-8219492 JDK-8223437: Backout JDK-8219974 Restore static callsite resolution for the current class JDK-8225217: Backout: JDK-8224814: Remove dead JNIHandleBlock freelist code JDK-8217658: baseline_cleanups from Async Monitor Deflation project JDK-8218145: block_if_requested is not proper inlined due to size JDK-8220394: bufferedStream does not honor size limit JDK-8224170: Build failures after JDK-8207812 (Implement Dynamic CDS Archive) JDK-8218140: Build failures after JDK-8218041 (Assorted wrong/missing includes) JDK-8223589: Build failures after JDK-8223534 (add back fixed test_markOop.cpp) JDK-8205645: Bump maximum recognized class file version to 57 for JDK 13 JDK-8224853: CDS address sanitizer errors JDK-8216184: CDS/appCDS tests failed on Windows due to long path to a classlist file JDK-8216010: Change callers of build_u2_from() to call Bytes::get_Java_u2() instead JDK-8059357: ClassVerifier redundantly checks constant pool entries multiple times JDK-8213153: Clean up GCC 8 errors JDK-8215644: Clean up globalDefinitions_.hpp JDK-8222231: Clean up interfaceSupport.inline.hpp duplicated code JDK-8218004: Clean up terminology for shared methods within the JVM for indy and condy support JDK-8189208: Cleanup ancient argument processing code JDK-8219860: Cleanup ClassFileParser::parse_linenumber_table JDK-8219630: cleanup hotspot ostream.cpp JDK-8194860: Cleanup Semaphore timed-wait time calculations JDK-8219712: code_size2 (defined in stub_routines_x86.hpp) is too small on new Skylake CPUs JDK-8216970: condy causes JVM crash JDK-8218994: Consolidate indy and condy JVM information within a BootstrapInfo data structure JDK-8222811: Consolidate MutexLockerEx and MutexLocker JDK-8217766: Container Support doesn't work for some Join Controllers combinations JDK-8218483: Crash in "assert(_daemon_threads_count->get_value() > daemon_count) failed: thread count mismatch 5 : 5" JDK-8221351: Crash in KlassFactory::check_shared_class_file_load_hook JDK-8220786: Create new switch to redirect error reporting output to stdout or stderr JDK-8220351: Cross-modifying code JDK-8225016: Dead code due to VMOperationQueue::add() always returning true JDK-8213399: DecoderLocker is unused JDK-8221734: Deoptimize with handshakes JDK-8214719: Deprecate -Xverify:none option JDK-8220050: Deprecate -XX:-ThreadLocalHandshakes JDK-8221180: Deprecate AllowJNIEnvProxy JDK-8218995: Deprecate the -XX:FailOverToOldVerifier option JDK-8221096: Description of -XX:+PrintFlagsRanges is incorrect JDK-8221478: Disable VerifySharedSpaces by default JDK-8224750: Display thread once in Internal exceptions event log lines JDK-8218751: Do not store original classfiles inside the CDS archive JDK-8225789: Empty method parameter type should generate ClassFormatError JDK-8221724: Enable archiving of Strings with hash 0 JDK-8216157: Enable inlining of java_lang_Class::is_primitive JDK-8217325: Enable inlining of java_lang_Class::oop_size_raw JDK-8219247: Enable inlining of newly introduced PlatformMonitor methods JDK-8221738: ErrorFile option does not handle pre-existing error files of the same name JDK-8204551: Event descriptions are truncated in logs JDK-8225402: events logging in deoptimization.cpp should go to deopt-log JDK-8153413: Exceptions::_throw always logs exceptions, penalizing performance JDK-8214271: Fast primitive to wake many threads JDK-8203469: Faster safepoints JDK-8221175: Fix bad function case for controlled JVM crash on PPC64 big-endian JDK-8221472: Fix HandshakeSuspendExitTest JDK-8221992: Fix old method replacement in ResolvedMethodTable JDK-8222977: Fix shenandoah broken with JDK-8222811 JDK-8218266: G1 crash in AccessInternal::PostRuntimeDispatch JDK-8216560: gtest build broken on PPC64 and aarch64 JDK-8223481: gtest/GTestWrapper.java failed due to "assert(ret == 0) failed: sem_post failed; error='Invalid argument' (errno=EINVAL)" JDK-8218562: handle HOTSPOT_BUILD_COMPILER for clang/xlclang and cleanup HOTSPOT_BUILD_COMPILER settings JDK-8218565: HandleMark cleanup JDK-8223810: HotSpot compile warnings from VS2017 JDK-8226525: HotSpot compile-time error for x86-32 JDK-8217879: hs_err should print more instructions in hex dump JDK-8215977: hsdis installation documentation update JDK-8207812: Implement Dynamic CDS Archive JDK-8218164: Improve local control of compiler warnings JDK-8218988: Improve metaspace verifications JDK-8214442: Improve stack walk API by adding handle marks JDK-8220658: Improve the readability of container information in the error log JDK-8218581: Incorrect exception message generation JDK-8224010: Incorrect string interning JDK-8222226: increase default timeout for runtime/7158800/InternTest.java JDK-8221477: Inject os/cpu-specific constants into Unsafe from JVM JDK-8217765: Internal Error (javaCalls.cpp:61) guarantee(thread->can_call_java()) failed JDK-8221967: InternTest.java timed out JDK-8222297: IRT_ENTRY/IRT_LEAF etc are the same as JRT JDK-8225453: is_busy diagnostics and other baseline cleanups from Async Monitor Deflation project JDK-8222327: java_lang_Thread _thread_status_offset, remove pre 1.5 code paths JDK-8221480: jcmd VM.metaspace shall print limits in basic mode JDK-8228585: jdk/internal/platform/cgroup/TestCgroupMetrics.java - NumberFormatException because of large long values (memory limit_in_bytes) JDK-8215961: jdk/jfr/event/os/TestCPUInformation.java fails on AArch64 JDK-8215311: JEP 350: Dynamic CDS Archives JDK-8222379: JFR TestClassLoadEvent.java failed due to EXCEPTION_ACCESS_VIOLATION JDK-8218851: JVM crash in custom classloader stress test, JDK 12 & 13 JDK-8210457: JVM crash in ResolvedMethodTable::add_method(Handle) JDK-8228407: JVM crashes with shared archive file mismatch JDK-8226406: JVM fails to detect mismatched or corrupt CDS archive JDK-8217618: JVM TI SuspendThread doesn't suspend the current thread before returning JDK-8219562: Line of code in osContainer_linux.cpp#L102 appears unreachable JDK-8220781: linux-s390 : os::get_summary_cpu_info gives bad output JDK-8219229: Make ConstantPool::tag_at and release_tag_at_put inlineable JDK-8074355: make MutexLocker smarter about non-JavaThreads JDK-8223956: Make SymbolTable and StringTable AllStatic JDK-8218147: make_walkable asserts on multiple calls JDK-8222893: markOopDesc::print_on() is a bit confused JDK-8217512: Message of LinkageError: use 'class' etc. instead of 'type' JDK-8219574: Minimal VM build failure after JDK-8219414 JDK-8223064: Minor cleanups in ResolvedMethodTable JDK-8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX JDK-8222936: mlvm/anonloader/stress/randomBytecodes/Test.java fails due to "ERROR: There were 1 hangups during parsing." JDK-8217659: monitor_logging updates from Async Monitor Deflation project JDK-8222295: more baseline cleanups from Async Monitor Deflation project JDK-8221350: more monitor logging updates from Async Monitor Deflation project JDK-8215731: Move forward class definitions out of globalDefinitions.hpp JDK-8223626: move print() functions to cpp files JDK-8221726: Multiple build failures after JDK-8221698 (Remove redundant includes from popular header files) JDK-8219112: name_and_sig_as_C_string usages in frame_s390 miss ResourceMark JDK-8214180: Need better granularity for sleeping JDK-8214162: Need to add new flag ExtensiveErrorReports to the command-line flags section in the java command reference JDK-8228764: New library dependencies due to JDK-8222720 JDK-8218558: NMT stack traces in output should show mt component for virtual memory allocations JDK-8199746: NMT: Breakup overused mtInternal into more fine grained categories. JDK-8219244: NMT: Change ThreadSafepointState's allocation type from mtInternal to mtThread JDK-8200109: NMT: diff_malloc_site assert(early->flags() == current->flags(), "Must be the same memory type") JDK-8218566: NMT: missing memory tag for assert poison page JDK-8219370: NMT: Move synchronization primitives from mtInternal to mtSynchronizer JDK-8204552: NMT: Separate thread stack tracking from virtual memory tracking JDK-8214975: No hs-err file if fatal error is raised during dynamic initialization. JDK-8227117: normal interpreter table is not restored after single stepping with TLH JDK-8222637: Obsolete NeedsDeoptSuspend JDK-8218753: Obsolete nonproduct flag ProfilerCheckIntervals JDK-8219459: oopDesc::is_valid() is broken JDK-8217442: Optimize native accesses to String.value JDK-8220366: Optimize Symbol handling in ClassVerifier and SignatureStream JDK-8224871: os::attempt_reserve_memory_at() tries too hard JDK-8224793: os::die() does not honor CreateCoredumpOnCrash option JDK-8221149: os::malloc checks MallocCatchPtr outside of ifdef ASSERT block JDK-8217994: os::print_hex_dump should be more resilient against unreadable memory JDK-8214816: os::read() should not transition to _thread_blocked with safepoint check on Solaris JDK-8224033: os::snprintf should be used in virtualizationSupport.cpp JDK-8222387: Out-of-bounds access to CPU _family_id_xxx array JDK-8224487: outputStream should not be copyable JDK-8217843: Performance regression related to os::supports_monotonic_clock() on linux JDK-8220794: PPC64: Fix signal handler for SIGSEGV on branch to illegal address JDK-8223395: PPC64: Improve comments in the JVM signal handler to match ISA text JDK-8219460: ppc: adjust NativeGeneralJump::insert_unconditional to stack allocated MacroAssembler JDK-8221470: Print methods in exception messages in java-like Syntax. JDK-8217315: Proper units should print more significant digits JDK-8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 JDK-8222720: Provide extended VMWare/vSphere virtualization related info in the hs_error file on linux/windows x86_64 JDK-8224816: Provide os::processor_id() implementation for Mac OS JDK-8222280: Provide virtualization related info in the hs_error file on AIX JDK-8219746: Provide virtualization related info in the hs_error file on linux ppc64 / ppc64le JDK-8217786: Provide virtualization related info in the hs_error file on linux s390x JDK-8219368: Quarantine runtime/NMT/CheckForProperDetailStackTrace.java test JDK-8220496: Race in java_lang_String::length() when deduplicating JDK-8221833: Readability check in Symbol::is_valid not performed for some addresses JDK-8221207: Redo JDK-8218446 - SuspendAtExit hangs JDK-8219974: REDO JDK-8219492: Restore static callsite resolution for the current class JDK-8224023: Redo the fix for ErrorFile option does not handle pre-existing error files of the same name JDK-8218675: Reduce verification overhead in ClassFileParser JDK-8219713: Reduce work in DefaultMethods::generate_default_methods JDK-8219554: Redundant lookup_common in SymbolTable::add JDK-8217660: Refactor module related locked_create_entry_or_null() functions JDK-8218755: Refix Symbol leak in prepend_host_package_name JDK-8183004: Remove code related to gtest death tests from assert macro JDK-8214821: Remove ConcurrentHashTable::get_copy JDK-8212949: Remove ConstantPoolCache::is_constantPoolCache JDK-8218738: Remove dead code in Symbol and friends JDK-8224814: Remove dead JNIHandleBlock freelist code JDK-8216188: Remove expired flags in JDK 13 JDK-8216191: Remove FastSuperclassLimit JDK-8224497: Remove FIXME in metaspaceClosure.cpp JDK-8215155: Remove get_insert() from concurrent hashtable and gtests JDK-8216428: Remove IgnoreLibthreadGPFault JDK-8216189: Remove Klass::compute_is_subtype_of JDK-8217998: Remove method_type field associated with the appendix field of an indy or method handle call JDK-8224203: Remove need to specify type when using FLAG_SET macros JDK-8221698: Remove redundant includes from popular header files JDK-8219579: Remove redundant signature parsing from the verifier JDK-8210832: Remove sneaky locking in class Monitor JDK-8219611: Remove superfluous sigfillset code JDK-8217424: Remove the idempotent parameter to Method::sort_methods JDK-8223306: Remove threads linked list (use ThreadsList's array in SA) JDK-8222518: Remove unnecessary caching of Parker object in java.lang.Thread JDK-8217841: Remove unused class TraceCPUTime JDK-8216197: Remove unused new_hash methods JDK-8223657: Remove unused THREAD argument from SymbolTable functions JDK-8219619: Remove UseFakeTimers and related code JDK-8221872: Remove uses of ClassLoaderWeakHandle typedef in protection domain table JDK-8224790: Remove Xusage.txt file JDK-8222502: Replace 19,20 case alternatives with JVM_CONSTANT_Module/Package names JDK-8218811: replace open by os::open in hotspot coding JDK-8221393: ResolvedMethodTable too small for StackWalking applications JDK-8219492: Restore static callsite resolution for the current class JDK-8219577: Returning NULL in a function which returns bools JDK-8220795: Rework naked_short_nanosleep on Windows to improve time-to-safepoint JDK-8222558: Rework ResolvedMethodTable verification JDK-8214097: Rework thread initialization and teardown logic JDK-8224952: RI deviates from JVMS - non-zero minor_version for class files throws UnsupportedClassVersionError. JDK-8217921: Runtime dead code removal JDK-8222500: runtime/8176717/TestInheritFD.java failed with java.nio.file.NoSuchFileException: /tmp/communication7071713601211876892.txt JDK-8224692: runtime/appcds tests crash in "HotSpotJVMCI::compute_offset" when running in Graal as JIT mode JDK-8220085: runtime/CompressedOops/UseCompressedOops.java times out on Windows intermittently JDK-8188872: runtime/ErrorHandling/TimeoutInErrorHandlingTest.java fails intermittently JDK-8222292: runtime/exceptionMsgs/ArrayIndexOutOfBoundsException/ArrayIndexOutOfBoundsExceptionTest.java timeout but test passed JDK-8222550: runtime/MemberName/MemberNameLeak.java times out JDK-8227041: runtime/memory/RunUnitTestsConcurrently.java has a memory leak JDK-8218399: runtime/RedefineObject/TestRedefineObject.java timeout JDK-8228650: runtime/SharedArchiveFile/CheckDefaultArchiveFile.java test fails on AIX JDK-8223194: runtime/Shutdown/ShutdownTest.java due to "OutOfMemoryError: Java heap too small" JDK-8216589: s390x build failures after JDK-8216167 (Update include guards to reflect correct directories) JDK-8224119: Safepoint cleanup logging logs times for things it doesn't do JDK-8225702: Safepoint counter can't be used for safepoint detection JDK-8219436: Safepoint logs correction and misc JDK-8220151: SafepointTracing::end_of_last_safepoint_ms should return ms since epoch. JDK-8215495: Set isCopy to JNI_FALSE if len == 0 JDK-8218151: Simplify JavaThread::thread_state definition JDK-8224201: Simplify JVM flag macro expansions JDK-8222015: Small VM.metaspace improvements JDK-8224795: some runtime/SelectionResolution tests are timing out JDK-8213397: Stack dump should show more clearly when a thread is blocked on a class initialization monitor JDK-8216302: StackTraceElement::fill_in can use cached Class.name JDK-8216308: StackTraceElement::fill_in can use injected Class source-file JDK-8219685: Startup failure: assert(!Universe::is_module_initialized()) failed: Incorrect java.lang.Module pre module system initialization JDK-8225225: stringStream internal buffer should always be zero terminated JDK-8224193: stringStream should not use Resource Area JDK-8216049: stringTable::intern creates redundant String when looking up existing one JDK-8215962: Support ThreadPriorityPolicy mode 1 for non-root users on linux/bsd JDK-8218446: SuspendAtExit hangs JDK-8218593: Symbol leak in prepend_host_package_name JDK-8213753: SymbolTable is double walked during class unloading and clean up table timing in do_unloading JDK-8216136: Take Compile_lock for SystemDictionary::_modification_counter with safepoint check JDK-8223190: Test gc/arguments/TestShrinkHeapInSteps.java breaks with change for JDK-8074355 JDK-8224151: Test vmTestbase/nsk/sysdict/vm/stress/chain/chain007/chain007.java might hang with release binaries JDK-8219441: test_logMessageTest missing static storage JDK-8220724: TestBiasedLockRevocationEvents fails while matching revoke events to VMOperation events JDK-8222034: Thread-SMR functions should be updated to remove work around JDK-8213231: ThreadSnapshot::_threadObj can become stale JDK-8223412: tier1 build failure after 8222893 JDK-8221643: Tighten up assert(_keep_alive >= 0) in CLD::inc_keep_alive JDK-8215791: Tiny bug in VM monitoring/management JDK-8219584: Try to dump error file by thread which causes safepoint timeout JDK-8217318: Unneeded handleization in InstanceKlass::restore_unshareable_info JDK-8223391: Unsynchronized iteration of ClassLoaderDataGraph JDK-8216167: Update include guards to reflect correct directories JDK-8223287: Update java manpage for Application Class Data Sharing JDK-8224763: Update man pages to show deprecation of -Xverify:none JDK-8223231: Update manpage with new semantics of ErrorFile option JDK-8227496: Update NUM_CDS_REGIONS and CURRENT_CDS_ARCHIVE_VERSION in cds.h JDK-8216426: Usage of array placement new may lead to memory corruption JDK-8215228: Use a constant hash table size in order to enable compiler optimization JDK-8223313: Use handshakes for CountStackFrames. JDK-8222988: Use MonitorLocker rather than MutexLocker when wait/notify used JDK-8217378: UseCriticalCMSThreadPriority is broken JDK-8217628: Verbose ArrayIndexOutOfBoundsException message also in JNI calls. JDK-8222534: VerifyBeforeExit is not honored when System.exit is called JDK-8218939: vm/mlvm/anonloader/stress/byteMutation crashed on windows JDK-8223585: vmTestbase/runtime/pcl/* get SEGV in MetadataOnStackClosure::do_metadata(Metadata*)+0x0 JDK-8223472: volatile long field corruption on x86_32 JDK-8193234: When using -Xcheck:jni an internally allocated buffer can leak JDK-8221408: Windows 32bit build build errors/warnings in hotspot JDK-8222300: Zero build broken after JDK-8222231 JDK-8220283: ZGC fails to build on GCC 4.4.7: ATTRIBUTE_ALIGNED compatibility issue JDK-8223572: ~ThreadInVMForHandshake() should call handle_special_runtime_exit_condition() hotspot/svc: JDK-8224230: [PPC64, s390] Support AsyncGetCallTrace JDK-8223779: Build failure after 8223040 (Add a AsyncGetCallTrace test) JDK-8224796: C code is not compiled correctly due to undefined "i386" JDK-8221915: cleanup ticks related coding in os_perf_aix.cpp [aix] JDK-8181383: com/sun/jdi/OptionTest.java fails intermittently with bind failed: Address already in use JDK-8221532: Incorrect copyright header in FileSystemSupport_md.c JDK-8224600: Provide VM.events command JDK-8225388: Running jcmd Compiler.CodeHeap_Analytics all 0 cause crash. JDK-8205654: serviceability/dcmd/framework/HelpTest.java timed out JDK-8225348: serviceability/dcmd/vm/EventsTest.java failed JDK-8219023: Sync JVMTI, JDI, and JDWP spec versions with JDK version JDK-8228658: test GetTotalSafepointTime.java fails on fast Linux machines with Total safepoint time 0 ms hotspot/svc-agent: JDK-8217612: (CL)HSDB cannot show some JVM flags JDK-8209413: AArch64: NPE in clhsdb jstack command JDK-8221396: Clean up serviceability/sa/TestUniverse.java JDK-8217850: CompressedClassSpaceSizeInJmapHeap fails after JDK-8217612 JDK-8220682: Heap dumping and inspection fails with JDK-8214712 JDK-8163805: hotspot/test/serviceability/sa/sadebugd/SADebugDTest.java failed with timed out JDK-8215568: Refactor SA clhsdb tests to use ClhsdbLauncher JDK-8214756: SA should ignore archived java heap objects that are not in use JDK-8217845: SA should refer const values for JVMFlag from HotSpot JDK-8218743: SA: Add support for large bitmaps JDK-8218733: SA: CollectedHeap provides broken implementation for used() and capacity() JDK-8223665: SA: debugd options should follow jhsdb style JDK-8218922: SA: Enable best-effort implementation of live regions iteration for ZGC JDK-8218970: SA: Enable HeapHprofBinWriter for ZGC JDK-8218978: SA: Enable more ZGC testing JDK-8218746: SA: Implement discontiguous bitmap for ZGC JDK-8218734: SA: Incorrect and raw loads of OopHandles JDK-8223814: SA: jhsdb common help needs to be more detailed JDK-8219414: SA: jhsdb jsnap throws UnmappedAddressException with core generated by gcore JDK-8215544: SA: Modify ClhsdbLauncher to add sudo privileges to enable MacOS tests on Mach5 JDK-8219003: SA: Refactor live regions iteration in preparation for JDK-8218922 JDK-8181313: SA: Remove libthread_db dependency on Linux JDK-8218732: SA: Resolves ZPageAllocator::_physical incorrectly JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP docker containers JDK-8218731: SA: Use concrete class as the return type of VMObjectFactory.newObject JDK-8213457: serviceability/sa/ClhsdbInspect.java time out JDK-8221917: serviceability/sa/TestPrintMdo.java fails on 32-bit platforms JDK-8220602: Shenandoah-SA: Enable best-effort implementation of heap walk JDK-8225801: Shenandoah: Adjust SA to reflect recent forwarding pointer changes JDK-8203364: Some serviceability/sa/ tests intermittently fail with java.io.IOException: LingeredApp terminated with non-zero exit code 3 hotspot/test: JDK-8218017: Application with a lot of threads stuck during exit related to java.util.logging.LogManager$Cleaner shutdown hook JDK-8222414: bring googlemock v1.8.1 JDK-8158048: Fix failure message from jtreg gtest wrapper JDK-8209917: fix TODO in GatherDiagnosticInfoObserver JDK-8224945: googlemock update breaks the build of arm32 and ppc JDK-8209807: improve handling exception in requires.VMProps JDK-8219395: integrate gcov w/ run-test JDK-8219139: move hotspot tests from test/jdk/vm JDK-8219149: ProcessTools.ProcessBuilder should print timing info for subprocesses JDK-8217520: Remove vm.opt.MaxGCPauseMillis == "null" from TestOldGenCollectionUsage.java JDK-8189400: testlibrary_tests are not tested in hotspot tiers JDK-8222154: upgrade gtest to 1.8.1 JDK-8219158: use 'test.root' property instead of traversing test-src path infrastructure: JDK-8221857: Collect code coverage for a subset of code JDK-8215729: Enhance makefiles to allow collecting code coverage with JCov JDK-8227247: tools/sjavac/IdleShutdown.java fails with AssertionError: Error too big on windows JDK-8225134: Update man-page files JDK-8219906: Update test documentation with default test jobs settings infrastructure/build: JDK-8217404: --with-jvm-features doesn't work when multiple features are explicitly disabled JDK-8217613: [AOT] TEST_OPTS_AOT_MODULES doesn't work on mac JDK-8225489: accessibility issues in pandoc-generated tables JDK-8222444: Add a suggestion for non-US locale in the test doc JDK-8222522: Add configure options for Mac Bundle creation JDK-8223319: Add copyright footer to specs and man pages JDK-8222913: Add Jib support for VERSION_EXTRA* JDK-8225066: Add missing file JDK-8219393: Add native library support for microbenchmarks JDK-8221894: Add notes for docker tests in the test doc JDK-8221988: add possibility to build with Visual Studio 2019 JDK-8218057: Add ppc64le and s390x profiles to jib-profiles.js JDK-8217626: Add setup/teardown functionality to RunTest JDK-8223678: Add Visual Studio Code workspace generation support (for native code) JDK-8218965: aix: support xlclang++ in the compiler detection JDK-8219129: Allow overriding of license files in legal dir JDK-8223667: ASAN build broken JDK-8221880: Better customization for Windows RC properties FileDescription and ProductName JDK-8221996: Bootcycle build broken JDK-8226404: bootcycle build uses wrong CDS archive JDK-8220530: Build compare script does not compare the contents of the test image JDK-8224145: Build compare script fails intermittently on test image native libraries JDK-8217916: Build compare script is not comparing jmods JDK-8225140: Build fails if directory contains 'unix' JDK-8218736: Build warning in lib/JvmFlags.gmk: extraneous text after 'ifeq' directive JDK-8218177: Bump jib format_version to support new devkit archive layout JDK-8221414: Bump required boot jdk version to 12 JDK-8217739: Cannot reuse java.base UnixConstants.java from target in BuildJDK when cross compiling JDK-8220093: Change to GCC 8.2 for building on Linux at Oracle JDK-8219988: Change to Visual Studio 2017 15.9.6 for building on Windows at Oracle JDK-8219986: Change to Xcode 10.1 for building on Macosx at Oracle JDK-8217448: Check for pandoc availability using ENABLE_PANDOC and not PANDOC JDK-8217032: Check pandoc capabilities in configure JDK-8218186: Clean up CLDR generation in build JDK-8221979: Cleanups for building Windows resources JDK-8223335: Compare baseline builds on linux are failing JDK-8225392: Comparison builds are failing due to cacerts file JDK-8218807: Compilation database (compile_commands.json) may contain obsolete items JDK-8224087: Compile C code for at least C99 Standard compliance JDK-8219788: Configure recommends JDK 8 JDK-8225346: Convert file to HTML5 JDK-8224166: Create a taglet to better handle @jls and @jvms tags JDK-8210834: Cross compilation triggers rebuild even without changes JDK-8209381: Default CDS classlist generation should run with an explicit locale setting JDK-8205934: Define jdk -source/-target version in version-numbers file JDK-8219920: dependency help output in configure-step : support zypper tool JDK-8216275: Disable annotation processing lint warnings when building microbenchmarks JDK-8224677: Dtrace .d files clash with make dependency .d files JDK-8215445: Enable building for Windows in WSL JDK-8223307: enable the Stack Execution Disable flag for JDK binaries on AIX JDK-8217761: Enhance run-test-prebuilt jib profile to support running tests with JCov JDK-8219391: extend gcov support to llvm/clang JDK-8224011: Failure handling in ExecuteWithLog fails in run-test-prebuilt JDK-8226538: find-files.gmk gets corrupted if tab completion is used before running make first JDK-8221621: FindTests.gmk cannot handle "=" in TEST.groups comments JDK-8220164: Fix build instructions for AIX JDK-8216278: Fix devkit and basic Jib support on WSL JDK-8216048: Fix devkit creation in WSL JDK-8216267: Fix hotspot-ide-project target on WSL JDK-8224257: fix issues in files generated by pandoc JDK-8227636: Fix output dir for jlink_jre target in Images.gmk JDK-8221434: Fix typo in lib-x11 autoconf error message about missing headers JDK-8223944: fix zlib related building docu and comments JDK-8160926: FLAGS_COMPILER_CHECK_ARGUMENTS doesn't handle cross-compilation JDK-8220363: hotspot-ide project fails JDK-8220784: hsdis cannot be built with MinGW64 JDK-8217357: Implement JCov jib profiles JDK-8221762: Improve Main.gmk/FindTests.gmk bootstrap time JDK-8223464: Improve version string for Oracle CI builds JDK-8218431: Improved platform checking in makefiles JDK-8220383: Incremental build is broken and inefficient JDK-8219971: Introduce SetupExecute in build system JDK-8216489: Issues with ModulePackages attribute generation on incremental build JDK-8223627: jdk-13+20 bundle name contains null instead of ea JDK-8220155: JDK-8219971 broke hotspot build JDK-8220529: JDK-8220383 broke test image build JDK-8217979: lib-freetype related configure messages contain wrong configure flag names JDK-8217896: Make better use of LCPUs when building on AIX JDK-8211016: make images does not update jdk/lib/src.zip with latest changes JDK-8226910: make it possible to use jtreg's -match via run-test framework JDK-8221907: make reconfigure breaks when configured with relative paths JDK-8218413: make reconfigure ignores configure-time AUTOCONF environment variable JDK-8217733: Minor RunTest fixes JDK-8219394: Missing FIXPATH in microbenchmark test runner JDK-8220504: Move definition of JAVA_VERSION_INFO_RESOURCE to Launcher-java.base.gmk JDK-8204564: Need better error output when GenerateLinkOptData fails JDK-6442874: Need to keep new errors from occuring in javadoc comments JDK-8226269: Race in SetupProcessMarkdown JDK-8218135: Redo: Add ppc64le and s390x profiles to jib-profiles.js JDK-8221764: Reduce make Init.gmk logging overhead JDK-8189861: Refactor CacheFind JDK-8222150: Refactor CheckReleaseDate.java test JDK-8217638: Remove old way of running tests (test/Makefile) JDK-8222627: Remove sneaky token 'Name' in jdk-version.m4 JDK-8221610: Resurrect (legacy) JRE bundle target JDK-8218198: Revert devkit change in JDK-8217910 for linux-x64 JDK-8218084: Revert JDK-8218057 JDK-8221703: Rmic build for java.management.api has bad incremental behavior JDK-8193255: Root Certificates should be stored in text format and assembled at build time JDK-8217634: RunTest documentation and usability update JDK-8217910: Slow linking with devkit on Linux JDK-8222510: Small cleanup for JDK launcher's make file JDK-8217728: Speed up incremental rerun of "make hotspot" JDK-8217730: Split up MakeBase.gmk JDK-8215991: Stop hiding exception from ArtifactResolver failures in tests JDK-8220445: Support for side by side MSVC Toolset versions JDK-8218692: Switch to JCov build which supports byte code version 57 JDK-8223309: test failing due to self-assign-overloaded JDK-8226628: The copyright footer should be enclosed in