Scanning for resources on the user classpath from an annotation processor

Remi Forax forax at univ-mlv.fr
Mon Aug 9 09:28:56 UTC 2021


> From: "Graeme Keith Rocher" <graeme.rocher at oracle.com>
> To: "compiler-dev" <compiler-dev at openjdk.java.net>
> Sent: Monday, August 9, 2021 10:03:54 AM
> Subject: Re: Scanning for resources on the user classpath from an annotation
> processor

> Having thought about this some more, this request can be ignored as it would be
> better to implement the required functionality at the build tooling layer
> whereby the build tooling collects the beans.xml resources needed by the
> processor and specifies them as inputs (annotation processor arguments) in
> order for incremental compilation to work.

yes, it seems a better design :) 

> Apologies for the noise.

> Graeme

Rémi 

> From: Graeme Keith Rocher <graeme.rocher at oracle.com>
> Date: Wednesday, 4 August 2021 at 09:48
> To: compiler-dev at openjdk.java.net <compiler-dev at openjdk.java.net>
> Subject: Scanning for resources on the user classpath from an annotation
> processor

> Hi all,

> Apologies in advance if I am sending this to the wrong place.

> We have a requirement in the upcoming CDI lite specification to find “beans.xml”
> files in the user classpath from an annotation processor (Micronaut).

> The issue is that as far as I am aware there is no way to do this from an
> annotation processor since the “JavaFileManager” interface is inaccessible
> which provides this functionality via the “getClassLoader” method that accepts
> a location that can be the user classpath:

> [
> https://docs.oracle.com/en/java/javase/11/docs/api/java.compiler/javax/tools/JavaFileManager.html#getClassLoader%28javax.tools.JavaFileManager.Location%29
> |
> https://docs.oracle.com/en/java/javase/11/docs/api/java.compiler/javax/tools/JavaFileManager.html#getClassLoader(javax.tools.JavaFileManager.Location)
> ]

> We have an experimental and not officially supported hack in the Micronaut
> annotation processor to attempt to work around this which retrieves the
> “JavaFileManager” via reflection:

> [
> https://github.com/micronaut-projects/micronaut-core/blob/a949a27c69ff00fe50fa751adf0501540aee79b2/inject-java/src/main/java/io/micronaut/annotation/processing/visitor/JavaVisitorContext.java#L123-L142
> |
> https://github.com/micronaut-projects/micronaut-core/blob/a949a27c69ff00fe50fa751adf0501540aee79b2/inject-java/src/main/java/io/micronaut/annotation/processing/visitor/JavaVisitorContext.java#L123-L142
> ]

> However clearly this violates the JDKs direction in terms of closing more of the
> internals.

> I would like to request the addition of an officially supported way to do this
> via the APT API and am happy to contribute a proposal / JEP + PR if it means it
> can be taken forward since without this functionality it would mean that users
> will have to unnecessarily pollute the annotation processor classpath with JARs
> that aren’t required on that classpath.

> Thanks in advance for any feedback.

> Graeme
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210809/97a8470f/attachment-0001.htm>


More information about the compiler-dev mailing list