[wildfly-dev] JDK 20 Release Candidate and Deprecation

Welcome to the latest OpenJDK Quality Outreach update! The first Release Candidates of JDK 20 have been released [1] as per the schedule [2]. At this stage, only P1 issues will be evaluated. And with the JDK 20 General Availability sets for March 21st, it is now time to fully focus on JDK 21. I'd like to thank those of you who have already provided feedback on the Early Builds of JDK 21. Feedback is always extremely useful, even more, when it comes early in the development cycle. We are always thinking about the future but the future is not limited to new features (pun intended). Properly removing legacy features from the platform is also critical. Deprecation has always been an important, phased, and ongoing effort. To name just two recent examples, `Thread.stop()` is removed in JDK 20 [3], and the URL Public Constructors are deprecated in JDK 20 (see the related heads-up below). It is important to prepare your codebase for such upcoming evolution sooner rather than later. To conclude on deprecation, I'll mention my colleague Nicolai who recently did a full video on this exact topic, i.e. "Prepare your Codebase for the Future Now!" [4]. [1] https://mail.openjdk.org/pipermail/jdk-dev/2023-February/007364.html [2] https://openjdk.org/projects/jdk/20/ [3] https://inside.java/2022/11/09/quality-heads-up/ [4] https://inside.java/2023/02/02/newscast-41/ ## Heads-Up - JDK 20 - Deprecate URL Public Constructors The `java.net.URL` class, dating from Java SE 1.0, does not encode or decode any URL components according to the RFC2396 escaping mechanism. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields that are returned from URL. This has led to many usability issues, including some potential vulnerabilities when the calling code did not take this into consideration. In Java SE 1.4, the `java.net.URI` class has been added to mitigate some of the `java.net.URL` shortcomings. It also offers methods to create an URL from an URI. JDK 20 will deprecate all public constructors of `java.net.URL`. This will provide a strong warning and discourage developers from using them. To construct a URL, the `URI::toURL` alternative should instead be preferred. To construct a `file:` based URL, `Path::toURI` should be used prior to `URI::toURL`. For more details, see https://bugs.openjdk.org/browse/JDK-8294241 ## Heads-Up - JDK 20 - JMX Connections Use an ObjectInputFilter by Default The default JMX agent now sets an ObjectInputFilter on the RMI connection to restrict the types that the server will deserialize. This should not affect normal usage of the MBeans in the JDK. Applications which register their own MBeans in the platform MBeanServer may need to extend the serialization filter to support any additional types that their custom MBeans accept as parameters. The default filter already covers any type that OpenMBeans and MXBeans might use. The serialization filter pattern is set in `JDK/conf/management/management.properties` using the property `com.sun.management.jmxremote.serial.filter.pattern`. If additional Java types need to be passed, the default can be overridden by running with `-Dcom.sun.management.jmxremote.serial.filter.pattern=.` Serialization Filtering and the filter pattern format are described in detail in the Core Libraries Guide [5]. [5] https://docs.oracle.com/en/java/javase/19/core/serialization-filtering1.h... ## Heads-Up - Testing Loom: Scoped Values and Structured Concurrency With one JEP in Preview (Virtual Threads - 2nd Preview) and two JEPs incubating (Scoped Values - Incubator & Structured Concurrency - 2nd Incubator) Loom made considerable progress in JDK 20. The Loom team is always eager to hear from developers experimenting with those APIs, especially given that both Scoped Values and Structured Concurrency might become Preview in JDK 21. Feedback should be reported to the loom-dev [6] mailing list. [6] https://mail.openjdk.org/pipermail/loom-dev/ ## JDK 20 Release Candidate builds The Release Candidate builds (builds 36) are available [7] and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [8]. [7] https://jdk.java.net/20/ [8] https://jdk.java.net/20/release-notes ### Changes in recent JDK 20 builds that may be of interest: - JDK-8300623: Lambda deserialization regression involving Enum method reference - JDK-8298400: Virtual thread instability when stack overflows - JDK-8298377: JfrVframeStream causes deadlocks in ZGC ## JDK 21 Early-Access builds The JDK 21 Early-Access (builds 9) are available [9], and are provided under the GNU General Public License v2, with the Classpath Exception. The related Javadocs are available here [10] and the Release Notes here [11]. [9] https://jdk.java.net/21/ [10] https://download.java.net/java/early_access/jdk21/docs/api/ [11] https://jdk.java.net/21/release-notes ### Changes in recent JDK 21 builds that may be of interest: - JDK-8299891: JMX ObjectInputFilter additional classes needed [Reported by Apache Derby] - JDK-8298478: (fs) Path.of should allow input to include long path prefix - JDK-8300869: Make use of the Double.toString(double) algorithm in java.ut… - JDK-8300891: Deprecate for removal javafx21x.swing.plaf.synth.SynthLookAndFee… - JDK-8286907: keytool should warn about weak PBE algorithms - JDK-8298445: Add LeakSanitizer support in HotSpot - JDK-8288050: SunJCE provider now supports SHA-512/224 and SHA-512/256 as digests for the PBES2 algorithms - JDK-8301207: (jdeps) Deprecate jdeps -profile option - JDK-8300247: Harden C1 xchg on AArch64 and PPC - JDK-8208077: File::listRoots Changed To Return All Available Drives On Windows - JDK-8300623: Lambda deserialization regression involving Enum method reference - JDK-8294680: Refactor scaled border rendering - JDK-8300584: Accelerate AVX-512 CRC32C for small buffers - JDK-8299896: Reduce enum values of HtmlLinkInfo.Kind - JDK-8300266: Detect Virtualization on Linux aarch64 - JDK-8298908: Instrument Metaspace for Asan ## Generational ZGC Early-Access Builds The latest Early-Access builds (build 21-genzgc+1-8 - 2023/1/27) of Generational ZGC [12] are available [13]. Those builds are based on an incomplete version of JDK 21 and are provided under the GNU General Public License, version 2, with the Classpath Exception. Feedback should be sent to the zgc-dev mailing list [14]. [12] https://bugs.openjdk.org/browse/JDK-8272979 [13] https://jdk.java.net/genzgc/ [14] https://mail.openjdk.org/pipermail/zgc-dev ## JavaFX 21 Early-Access Builds The Early-Access builds of the JavaFX runtime, built from openjdk/jfx [15], allow JavaFX application developers to build and test their applications with JavaFX 21 on JDK 21. The latest Early-Access builds (build 2 2023/1/27) are now available [16] under the GNU General Public License, version 2, with the Classpath Exception. The related Javadocs are available here [17]. Feedback should be sent to the openjfx-dev mailing list [18]. [15] https://github.com/openjdk/jfx [16] https://jdk.java.net/javafx21/ [17] https://download.java.net/java/early_access/javafx21/docs/api/index.html [18] http://mail.openjdk.org/mailman/listinfo/openjfx-dev ## Topics of Interest: - JDK 21 - Image Performance Improvements https://minborgsjavapot.blogspot.com/2023/02/jdk-21-image-performance-imp... - JDK 21 - Performance Improvements Revealed https://minborgsjavapot.blogspot.com/2023/01/java-21-performance-improvem... - From Java Security with Love - Inside Java Newscast #42 https://inside.java/2023/02/14/newscast-42/ - ZGC - The Future of Low-Latency Garbage Collection Is Here https://inside.java/2023/01/25/zgc/ - Draft JEP: JDK Packaging Guidelines https://mail.openjdk.org/pipermail/jdk-dev/2023-February/007327.html - Future Java - Prepare Your Codebase Now! - Inside Java Newscast #41 https://inside.java/2023/02/02/newscast-41/ - Java Modules in Real Life https://inside.java/2023/01/29/java-modules-in-real-life/ ~ Thanks for participating in the OpenJDK Quality Outreach program. And as always, if you find an issue, please let us know through the usual channels. -- David