Re: [External] : Re: JDK 23 Feature Freeze / New Loom EA builds

[David Delabassee]

Great, thanks for the update.

--David


From: Rick Hillegas 
Date: Tuesday, 11 June 2024 at 01:20
To: derby-dev@db.apache.org , 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$

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 

Re: JDK 23 Feature Freeze / New Loom EA builds

[Rick Hillegas]

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] 

[jira] [Commented] (DERBY-7163) Make it possible to build and test Derby with Open JDK 23

[Richard N. Hillegas (Jira)]

[ 
https://issues.apache.org/jira/browse/DERBY-7163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853806#comment-17853806
 ] 

Richard N. Hillegas commented on DERBY-7163:


Attaching derby-7163-01-aa-addJDK23vm.diff. This patch adds a JDK 23 test VM. 
Tests with this patch, using Open JDK build 23-ea+26-2269 passed cleanly using 
both the classpath and the modulepath. Derby builds and tests cleanly with that 
Open JDK build. The javadoc builds cleanly too.

Touches the following files:

{noformat}
M   
java/build/org/apache/derbyBuild/lastgoodjarcontents/insane.derbyTesting.jar.lastcontents
M   
java/build/org/apache/derbyBuild/lastgoodjarcontents/sane.derbyTesting.jar.lastcontents
M   
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/harness/JavaVersionHolder.java
A   
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/harness/jdk123.java
{noformat}


> Make it possible to build and test Derby with Open JDK 23
> -
>
> Key: DERBY-7163
> URL: https://issues.apache.org/jira/browse/DERBY-7163
> Project: Derby
>  Issue Type: Task
>  Components: Build tools
>Affects Versions: 10.18.0.0
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7163-01-aa-addJDK23vm.diff
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (DERBY-7163) Make it possible to build and test Derby with Open JDK 23

[Richard N. Hillegas (Jira)]

 [ 
https://issues.apache.org/jira/browse/DERBY-7163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard N. Hillegas updated DERBY-7163:
---
Attachment: derby-7163-01-aa-addJDK23vm.diff

> Make it possible to build and test Derby with Open JDK 23
> -
>
> Key: DERBY-7163
> URL: https://issues.apache.org/jira/browse/DERBY-7163
> Project: Derby
>  Issue Type: Task
>  Components: Build tools
>Affects Versions: 10.18.0.0
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7163-01-aa-addJDK23vm.diff
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes

[Richard N. Hillegas (Jira)]

[ 
https://issues.apache.org/jira/browse/DERBY-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853797#comment-17853797
 ] 

Richard N. Hillegas commented on DERBY-6445:


Linking this issue to DERBY-6834, another discussion about the precision of 
Derby's DATE/TIME/TIMESTAMP types.

> JDBC 4.2: Add support for new date and time classes
> ---
>
> Key: DERBY-6445
> URL: https://issues.apache.org/jira/browse/DERBY-6445
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.10.1.1
>Reporter: Knut Anders Hatlen
>Priority: Major
> Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, 
> derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, 
> derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, 
> derby-6445-02-aa-patchExplanation.diff, tweaks.diff
>
>
> JDBC 4.2 added type mappings for new date and time classes found in Java 8. 
> Derby should support these new mappings.
> This would at least affect Derby's implementation of the various getObject(), 
> setObject() and setNull() methods in ResultSet, PreparedStatement and 
> CallableStatement.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes

[Richard N. Hillegas (Jira)]

[ 
https://issues.apache.org/jira/browse/DERBY-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853796#comment-17853796
 ] 

Richard N. Hillegas commented on DERBY-6445:


Thanks for your thoughts, Philippe and Bryan. It seems that there is broad 
agreement that the precision of Derby's TIME datatype is outside the scope of 
this JIRA issue.

> JDBC 4.2: Add support for new date and time classes
> ---
>
> Key: DERBY-6445
> URL: https://issues.apache.org/jira/browse/DERBY-6445
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.10.1.1
>Reporter: Knut Anders Hatlen
>Priority: Major
> Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, 
> derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, 
> derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, 
> derby-6445-02-aa-patchExplanation.diff, tweaks.diff
>
>
> JDBC 4.2 added type mappings for new date and time classes found in Java 8. 
> Derby should support these new mappings.
> This would at least affect Derby's implementation of the various getObject(), 
> setObject() and setNull() methods in ResultSet, PreparedStatement and 
> CallableStatement.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes

[Bryan Pendleton (Jira)]

[ 
https://issues.apache.org/jira/browse/DERBY-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853720#comment-17853720
 ] 

Bryan Pendleton commented on DERBY-6445:


I think your reasoning is quite compelling, thank you for sharing that thought 
process.

I wonder, though: could we perhaps consider that a *different* enhancement, as 
it seems somewhat independent of this work?

That is, perhaps we can declare this work finished and track the sub-second 
behavior of TIME under a separate Jira work item?

> JDBC 4.2: Add support for new date and time classes
> ---
>
> Key: DERBY-6445
> URL: https://issues.apache.org/jira/browse/DERBY-6445
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.10.1.1
>Reporter: Knut Anders Hatlen
>Priority: Major
> Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, 
> derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, 
> derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, 
> derby-6445-02-aa-patchExplanation.diff, tweaks.diff
>
>
> JDBC 4.2 added type mappings for new date and time classes found in Java 8. 
> Derby should support these new mappings.
> This would at least affect Derby's implementation of the various getObject(), 
> setObject() and setNull() methods in ResultSet, PreparedStatement and 
> CallableStatement.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes

[Philippe Marschall (Jira)]

[ 
https://issues.apache.org/jira/browse/DERBY-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853703#comment-17853703
 ] 

Philippe Marschall commented on DERBY-6445:
---

I think there are two different questions:
# Should the code for this JIRA silently truncate {{LocalTime}} to seconds? I 
believe so based on the current behavior of {{java.sql.Time}}. I just wanted to 
bring it up as it may not be immediately obvious.
# Should {{TIME}} in Apache Derby support sub-second precision? If not should 
it silently truncate? This is a much boarder question that I believe goes 
beyond the scope of this JIRA.

Unfortunately I do not have access to the SQL standard. I would like make two 
arguments for {{TIME}} supporting sub-second resolution. The first is a 
conceptual one, if a {{TIMESTAMP}} is an aggregate of a {{DATE}} and a {{TIME}} 
and {{TIMESTAMP}} has a sub-second resolution doesn't that mean that {{TIME}} 
should also have a sub-second resolution? Second a lot of other RDBMS support 
sub-second resolution for {{TIME}}
* PosgreS https://www.postgresql.org/docs/current/datatype-datetime.html
* SQL Server 
https://learn.microsoft.com/en-us/sql/t-sql/data-types/time-transact-sql
* MySQL https://dev.mysql.com/doc/refman/8.4/en/fractional-seconds.html
* H2 http://www.h2database.com/html/datatypes.html#time_type
* HSQLDB 
https://www.hsqldb.org/doc/guide/sqlgeneral-chapt.html#sgc_datetime_types

Oracle does not have a {{TIME}} datatype and DB2 does not support sub-second 
resolution https://www.ibm.com/docs/en/db2-for-zos/13?topic=values-time 
https://www.ibm.com/docs/en/db2/11.5?topic=list-datetime-values

As for Derby itself {{org.apache.derby.iapi.types.SQLTime}} already has a 
{{#encodedTimeFraction}} that is currently always 0 as {{#computeEncodedTime}} 
does not read the milliseconds from the calendar.

The Derby client itself seems to support sub-second resolution for {{Time}} if 
I have a look at {{org.apache.derby.client.am.CrossConverters#setObject(int, 
Timestamp)}} or {{DateTimeValue#DateTimeValue(Time, Calendar)}}.

Whether {{java.sql.Time}} supports sub-second resolution or truncates to 
seconds is a bit more complicated. Unfortunately the class comment is not very 
clear. What speaks for the truncation is that both {{#toString()}} and 
{{#valueOf(LocalTime)}} both truncate to seconds. What speaks against it is 
that it is possible to get the milliseconds out again. If we create a 
{{Calendar}} from the {{Time}} we get the millisecond value.

{{code}}
Calendar creationCalendar = Calendar.getInstance();
creationCalendar.clear();
creationCalendar.set(Calendar.YEAR, 1970);
creationCalendar.set(Calendar.MONTH, Calendar.JANUARY);
creationCalendar.set(Calendar.DAY_OF_MONTH, 1);
creationCalendar.set(Calendar.HOUR_OF_DAY, 1);
creationCalendar.set(Calendar.MINUTE, 2);
creationCalendar.set(Calendar.SECOND, 3);
int millis = 456;
creationCalendar.set(Calendar.MILLISECOND, millis);

Time time = new Time(creationCalendar.getTimeInMillis());
Calendar readBack = Calendar.getInstance();
readBack.setTimeInMillis(time.getTime());
assertEquals(millis, readBack.get(Calendar.MILLISECOND));
{{code}}

However when going through Derby it is always truncated to seconds. I haven't 
debugged it but would assume because 
{{org.apache.derby.iapi.types.SQLTime#encodedTimeFraction}} is always 0.

> JDBC 4.2: Add support for new date and time classes
> ---
>
> Key: DERBY-6445
> URL: https://issues.apache.org/jira/browse/DERBY-6445
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.10.1.1
>Reporter: Knut Anders Hatlen
>Priority: Major
> Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, 
> derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, 
> derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, 
> derby-6445-02-aa-patchExplanation.diff, tweaks.diff
>
>
> JDBC 4.2 added type mappings for new date and time classes found in Java 8. 
> Derby should support these new mappings.
> This would at least affect Derby's implementation of the various getObject(), 
> setObject() and setNull() methods in ResultSet, PreparedStatement and 
> CallableStatement.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (DERBY-7163) Make it possible to build and test Derby with Open JDK 23

[Richard N. Hillegas (Jira)]

Richard N. Hillegas created DERBY-7163:
--

 Summary: Make it possible to build and test Derby with Open JDK 23
 Key: DERBY-7163
 URL: https://issues.apache.org/jira/browse/DERBY-7163
 Project: Derby
  Issue Type: Task
  Components: Build tools
Affects Versions: 10.18.0.0
Reporter: Richard N. Hillegas
Assignee: Richard N. Hillegas






--
This message was sent by Atlassian Jira
(v8.20.10#820010)

JDK 23 Feature Freeze / New Loom EA builds

[David Delabassee]

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