RFR: JDK-8306819: Consider disabling the compiler's default active annotation processing [v7]

[Joe Darcy]

On Thu, 30 Nov 2023 20:31:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have learned very late (about a month ago, and through JMH bug reports!) about this change.
> 
> Looking at incoming bug reports, I can see this is looking to break significant amount of day-to-day things that rely on annotation processing to work by default. This includes existing JMH benchmarks, existing JCStress tests, and that is only OpenJDK tools so far! The proposed fix, "enable the annotation processing in build" seems to underestimate how many already existing build configs _are there_, and how widespread annotation processing is. So this is a harbinger of a widespread breakage when updating to JDK 22 and beyond.
> 
> Yet, I see only tiny discussion about this in either here or in the CSR. It mostly just states that disabling annotation processors is the right thing to do to solve the externally reported problematic scenario. Normally, given the impact for changing a policy like this, I would have expected to see a JEP-sized discussion that weighs pros and cons for mitigation strategies, polls what problems real projects would run into, discusses to what extent we want to deal with currently supported JDK releases, etc.
> 
> After more digging, the only (?) discussions I could find is [Reddit post](https://www.reddit.com/r/java/comments/17f7dha/consider_disabling_the_compilers_default_active/) and this PR comments, which contain some valid questions, concerns, and scenarios the discussion for a change like this should consider.
> 
> Yes, there was a warning message. This only highlights that hardly anyone reads the warning messages, especially buried somewhere in CI logs. This also does not capture the unfortunate reality that JDK 21 only starts to see major use, so most users did not even had the opportunity to see the warning message! In other words, warning messages are inefficient tools to bring quick attention to the issue that proposes to change the JDK behavior in a considerable way.
> 
> IMO, JEPs are done for this reason, even for less impactful things. So I suggest we revert [JDK-8306819](https://bugs.openjdk.org/browse/JDK-8306819) from JDK 22, and start over with the JEP targeting JDK 23 or even 24. I believe this would be a right thing to do at this point.

Thanks for the input @shipilev ; I'm looking into options to amend this change later in JDK 22.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14432#issuecomment-1834565493