Re: [External] : Re: JDK 23 Feature Freeze / New Loom EA builds
Great, thanks for the update. --David From: Rick Hillegas Date: Tuesday, 11 June 2024 at 01:20 To: [email protected] , David Delabassee Subject: [External] : Re: JDK 23 Feature Freeze / New Loom EA builds Thanks for the heads-up, David. Derby builds and tests cleanly with Open JDK build 23-ea+26-2269. See https://urldefense.com/v3/__https://issues.apache.org/jira/browse/DERBY-7163__;!!ACWV5N9M2RV99hQ!Jtyo04cIUtWREGgL47qMhtLyWYc5dqYjDeFa85KReVbdRP3Z7uNw7ipp-qn4opq3-k8euHHkW7dSlVBdslHhi_YVX4Ut$<https://urldefense.com/v3/__https:/issues.apache.org/jira/browse/DERBY-7163__;!!ACWV5N9M2RV99hQ!Jtyo04cIUtWREGgL47qMhtLyWYc5dqYjDeFa85KReVbdRP3Z7uNw7ipp-qn4opq3-k8euHHkW7dSlVBdslHhi_YVX4Ut$> On 6/10/24 12:31 AM, David Delabassee wrote: > Welcome to the latest OpenJDK Quality Outreach update! > > JDK 23, scheduled for General Availability on September 17, 2024, is now in > Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 23 feature set > is frozen (see the final list of JEPs integrated into JDK 23 below) and only > low-risk enhancements might still be considered. The coming weeks should be > leveraged to identify and resolve as many issues as possible, i.e. before JDK > 23 enters the Release Candidates phase in early August [2]. We count on you > to test your projects and help us make JDK 23 another solid release! > > This time, we are covering several heads-up related to JDK 23 : Deprecate the > Memory-Access Methods in sun.misc.Unsafe for Removal and default annotation > processing policy change. Also, make sure to check the new Loom early-access > builds which have an improved Java monitors implementation to work better > with virtual threads. > > [1] https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009053.html > [2] https://openjdk.org/projects/jdk/23/ > > > ## Heads-Up - JDK 23: Deprecate the Memory-Access Methods in sun.misc.Unsafe > for Removal > > As mentioned in a previous communication [3], there’s a plan to ultimately > remove the sun.misc.Unsafe memory-access methods as the platform offers safer > alternatives. JEP 471 (Deprecate the Memory-Access Methods in sun.misc.Unsafe > for Removal) [4] outlines in more detail this plan including the initial step > which is happening in JDK 23, i.e., all of the sun.misc unsafe memory-access > methods are now marked as deprecated for removal. This will cause, in JDK 23, > compile-time deprecation warnings for code that refers to these methods, > alerting library developers to their forthcoming removal. A new command-line > option also enables application developers and users to receive runtime > warnings when those methods are used. > > Developers relying on those sun.misc.Unsafe APIs for access memory are > strongly encouraged to start, if they haven't done so yet, the migration from > the sun.misc.Unsafe APIs to supported replacements. For more details, make > sure to read JEP 471 (Deprecate the Memory-Access Methods in sun.misc.Unsafe > for Removal). > > [3] > https://mail.openjdk.org/pipermail/quality-discuss/2024-January/001132.html > [4] https://openjdk.org/jeps/471 > > > ## Heads-Up - JDK 23: Changes Default Annotation Processing Policy > > Annotation processing is a compile-time feature, where javac scans the > to-be-compiled source files for annotations and then the class path for > matching annotation processors, so they can generate source code. Up to JDK > 22, this feature is enabled by default, which may have been reasonable when > it was introduced in JDK 6 circa 2006, but from a current perspective, in the > interest of making build output more robust against annotation processors > being placed on the class path unintentionally, this is much less reasonable. > Hence, starting with JDK 23, javac requires an additional command-line option > to enable annotation processing. > > ### New `-proc` Value > To that end, the pre-existing option `-proc:$policy` was extended, where > `$policy` can now have the following values: > - `none`: compilation _without_ annotation processing, this policy exists > since JDK 6 > - `only`: annotation processing _without_ compilation, this policy exists > since JDK 6 > - `full`: annotation processing followed by compilation, this policy is the > default in JDK ≤22 but the value itself is new (see next section for versions > that support it) > > Up to and including JDK 22, code bases that require annotation processing > before compilation could rely on javac's default behavior to process > annotations but that is no longer the case. Starting with JDK 23, at least > one annotation-processing command line option needs to be present. If neither > `-processor`, `--processor-path`, now `--processor-module-path` is used, > `-p
Re: JDK 23 Feature Freeze / New Loom EA builds
Thanks for the heads-up, David. Derby builds and tests cleanly with Open JDK build 23-ea+26-2269. See https://issues.apache.org/jira/browse/DERBY-7163 On 6/10/24 12:31 AM, David Delabassee wrote: Welcome to the latest OpenJDK Quality Outreach update! JDK 23, scheduled for General Availability on September 17, 2024, is now in Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 23 feature set is frozen (see the final list of JEPs integrated into JDK 23 below) and only low-risk enhancements might still be considered. The coming weeks should be leveraged to identify and resolve as many issues as possible, i.e. before JDK 23 enters the Release Candidates phase in early August [2]. We count on you to test your projects and help us make JDK 23 another solid release! This time, we are covering several heads-up related to JDK 23 : Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal and default annotation processing policy change. Also, make sure to check the new Loom early-access builds which have an improved Java monitors implementation to work better with virtual threads. [1] https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009053.html [2] https://openjdk.org/projects/jdk/23/ ## Heads-Up - JDK 23: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal As mentioned in a previous communication [3], there’s a plan to ultimately remove the sun.misc.Unsafe memory-access methods as the platform offers safer alternatives. JEP 471 (Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal) [4] outlines in more detail this plan including the initial step which is happening in JDK 23, i.e., all of the sun.misc unsafe memory-access methods are now marked as deprecated for removal. This will cause, in JDK 23, compile-time deprecation warnings for code that refers to these methods, alerting library developers to their forthcoming removal. A new command-line option also enables application developers and users to receive runtime warnings when those methods are used. Developers relying on those sun.misc.Unsafe APIs for access memory are strongly encouraged to start, if they haven't done so yet, the migration from the sun.misc.Unsafe APIs to supported replacements. For more details, make sure to read JEP 471 (Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal). [3] https://mail.openjdk.org/pipermail/quality-discuss/2024-January/001132.html [4] https://openjdk.org/jeps/471 ## Heads-Up - JDK 23: Changes Default Annotation Processing Policy Annotation processing is a compile-time feature, where javac scans the to-be-compiled source files for annotations and then the class path for matching annotation processors, so they can generate source code. Up to JDK 22, this feature is enabled by default, which may have been reasonable when it was introduced in JDK 6 circa 2006, but from a current perspective, in the interest of making build output more robust against annotation processors being placed on the class path unintentionally, this is much less reasonable. Hence, starting with JDK 23, javac requires an additional command-line option to enable annotation processing. ### New `-proc` Value To that end, the pre-existing option `-proc:$policy` was extended, where `$policy` can now have the following values: - `none`: compilation _without_ annotation processing, this policy exists since JDK 6 - `only`: annotation processing _without_ compilation, this policy exists since JDK 6 - `full`: annotation processing followed by compilation, this policy is the default in JDK ≤22 but the value itself is new (see next section for versions that support it) Up to and including JDK 22, code bases that require annotation processing before compilation could rely on javac's default behavior to process annotations but that is no longer the case. Starting with JDK 23, at least one annotation-processing command line option needs to be present. If neither `-processor`, `--processor-path`, now `--processor-module-path` is used, `-proc:only` or `-proc:full` has to be provided. In other words, absent other command line options, `-proc:none` is the default on JDK 23. ### Migration to `-proc:full` Several measures were undertaken to help projects prepare for the switch to `-proc:full`: - As of the April 2024 JDK security updates, support for `-proc:full` has been backported to 17u (17.0.11) and 11u (11.0.23) for both Oracle JDK and OpenJDK distributions. Additionally, Oracle's 8u release (8u411) also supports `-proc:full`. - Starting in JDK 21, javac prints an informative message if implicit usage of annotation processing under the default policy is detected. With `-proc:full` backported, it is possible to configure a build that will work the same before and after the change in javac's default policy. Additional details can be found in the original proposal [5]. [5] https://mail.openjdk.org/pipermail/jdk-dev/2024-May/009028.htm
JDK 23 Feature Freeze / New Loom EA builds
Welcome to the latest OpenJDK Quality Outreach update! JDK 23, scheduled for General Availability on September 17, 2024, is now in Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 23 feature set is frozen (see the final list of JEPs integrated into JDK 23 below) and only low-risk enhancements might still be considered. The coming weeks should be leveraged to identify and resolve as many issues as possible, i.e. before JDK 23 enters the Release Candidates phase in early August [2]. We count on you to test your projects and help us make JDK 23 another solid release! This time, we are covering several heads-up related to JDK 23 : Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal and default annotation processing policy change. Also, make sure to check the new Loom early-access builds which have an improved Java monitors implementation to work better with virtual threads. [1] https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009053.html [2] https://openjdk.org/projects/jdk/23/ ## Heads-Up - JDK 23: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal As mentioned in a previous communication [3], there’s a plan to ultimately remove the sun.misc.Unsafe memory-access methods as the platform offers safer alternatives. JEP 471 (Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal) [4] outlines in more detail this plan including the initial step which is happening in JDK 23, i.e., all of the sun.misc unsafe memory-access methods are now marked as deprecated for removal. This will cause, in JDK 23, compile-time deprecation warnings for code that refers to these methods, alerting library developers to their forthcoming removal. A new command-line option also enables application developers and users to receive runtime warnings when those methods are used. Developers relying on those sun.misc.Unsafe APIs for access memory are strongly encouraged to start, if they haven't done so yet, the migration from the sun.misc.Unsafe APIs to supported replacements. For more details, make sure to read JEP 471 (Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal). [3] https://mail.openjdk.org/pipermail/quality-discuss/2024-January/001132.html [4] https://openjdk.org/jeps/471 ## Heads-Up - JDK 23: Changes Default Annotation Processing Policy Annotation processing is a compile-time feature, where javac scans the to-be-compiled source files for annotations and then the class path for matching annotation processors, so they can generate source code. Up to JDK 22, this feature is enabled by default, which may have been reasonable when it was introduced in JDK 6 circa 2006, but from a current perspective, in the interest of making build output more robust against annotation processors being placed on the class path unintentionally, this is much less reasonable. Hence, starting with JDK 23, javac requires an additional command-line option to enable annotation processing. ### New `-proc` Value To that end, the pre-existing option `-proc:$policy` was extended, where `$policy` can now have the following values: - `none`: compilation _without_ annotation processing, this policy exists since JDK 6 - `only`: annotation processing _without_ compilation, this policy exists since JDK 6 - `full`: annotation processing followed by compilation, this policy is the default in JDK ≤22 but the value itself is new (see next section for versions that support it) Up to and including JDK 22, code bases that require annotation processing before compilation could rely on javac's default behavior to process annotations but that is no longer the case. Starting with JDK 23, at least one annotation-processing command line option needs to be present. If neither `-processor`, `--processor-path`, now `--processor-module-path` is used, `-proc:only` or `-proc:full` has to be provided. In other words, absent other command line options, `-proc:none` is the default on JDK 23. ### Migration to `-proc:full` Several measures were undertaken to help projects prepare for the switch to `-proc:full`: - As of the April 2024 JDK security updates, support for `-proc:full` has been backported to 17u (17.0.11) and 11u (11.0.23) for both Oracle JDK and OpenJDK distributions. Additionally, Oracle's 8u release (8u411) also supports `-proc:full`. - Starting in JDK 21, javac prints an informative message if implicit usage of annotation processing under the default policy is detected. With `-proc:full` backported, it is possible to configure a build that will work the same before and after the change in javac's default policy. Additional details can be found in the original proposal [5]. [5] https://mail.openjdk.org/pipermail/jdk-dev/2024-May/009028.html ## Heads-up - Loom: New EA builds with improved Java monitors implementation to work better with virtual threads Project Loom published new early-access builds [6]. These builds have an improved
