Re: JDK 20 Release Candidate and Deprecation
Hello David, I ran the Ant testsuite against Java 20 build 20+36-2344 and Java 21 EA build 21-ea+11-905. No regressions were found: https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20Linux%20(latest%20EA%20JDK)/33/ https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20Linux%20(latest%20EA%20JDK)/34/ -Jaikiran On 15/02/23 10:54 am, David Delabassee wrote: 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 evolutions 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.html#GUID-55BABE96-3048-4A9F-A7E6-781790FF3480 ## 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
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 evolutions 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.html#GUID-55BABE96-3048-4A9F-A7E6-781790FF3480 ## 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]
