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

Chen Liang liach at openjdk.org
Sun Sep 10 15:35:45 UTC 2023

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. 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. Such classpath separation have already been promoted by build tools like Gradle.

After all, your build tool should be setting the `-proc` flag for you already, just like setting the classpath flags. You can first upgrade to Java 21, which has patch https://bugs.openjdk.org/browse/JDK-8310061 that warns you about implicit APs, before upgrading to 22 that changes the default behavior.


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

More information about the compiler-dev mailing list