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

[Josiah Noel]

On Sun, 10 Sep 2023 00:52:31 GMT, Rob Bygrave <duke at openjdk.org> wrote:

>> Change annotation processing to be opt-in rather than opt-out.
>
>> Based on my observations, nowadays annotation processing is hardly used anymore and if it's used it mostly occurs after the actual compilation process in a build tool
> 
> Annotation processing use is fundamental to newer frameworks like Quarkus, Micronaut and Spring framework is also adopting more use of annotation processing. This is because it enables frameworks and libraries to move some work from runtime to build time for reduced memory consumption and faster startup (replacing reflection, dynamic proxies etc).
> 
> For myself I have annotation processors that:
> - Perform Dependency Injection 
> - Generate JSON adapters (think Jackson without any runtime reflection, all the fastest JSON libs use annotation processing)
> - Generate Rest Http Clients (think JAX-RS Jersey client implemented as source code generation)
> - Generate Http Server controllers (think JAX-RS Jersey server implementation as source code generation)
> - Generate Validation adapters (think Jakarta Validation implemented as source code generation)
> - Generate "Builders" for record types
> 
> Its also common to use annotation processing for mapping/adapting between types (e.g. MapStruct)
> 
> I'd suggest the use of annotation processing is actually taking off in the last say 5 years as we especially look to deploy applications into cloud hosted environments where we pay money for the amount of CPU and Memory used.  Annotation processing means that a **_LOT_** of libraries can move some or even most of their functionality to build time reducing the CPU required to initialise the library and the total memory consumption.
> 
> 
>> Based on my observations, nowadays annotation processing is hardly used anymore
> 
> To me I see the exact opposite happening and it's driven by cloud adoption and the desire to move work from runtime to build time.

> @rbygrave This patch isn't aimed to remove AP. 

Pretty sure he was only speaking against the statement that AP is an unused feature. 

> This aims to avoid unintentional AP pollutions in classpath, like if one AP is present in a dependency and thus your classpath but you don't want it to run. 

In practice is this a thing that happens? Most processors I've seen (like Lombok or record builder for example) are typically added as provided or optional scope dependencies. (and so cannot be transitively pulled)

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

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