*> there are three invocations of javac* For me I'd describe it as only 2 invocations of javac.
That is, what above has as "second compilation" and "third compilation" is I'd say is just 1 invocation of javac of the "example" module that includes an annotation processor. I'd describe it as 1 invoke of javac will potentially involve a number of *rounds* until it's done. Some application source is compiled, which then invokes the annotation processor that generates source, that is then compiled, which can then invoke other annotation processors etc and this continues until it does the final round (which we can detect in the annotation processor via RoundEnvironment.processingOver() - and we get a nice warning if the annotation processor generates stuff in the final round). Obviously this is pretty darn cool how javac does this as it means we can have "normal source" depend on generated code which won't exist until compilation starts (chicken and egg). I was sure this "multi-round compilation dance" is just a single invoke of javac. Is it not? So my take is that this 1 invoke of javac when done with JPMS (tooling wise the presence of a module-info) is now "tighter" and specifically this *javac* can only see things defined in the module-info (and java.compiler is not in there generally) ... hence the generated source which is also compiled by this invoke of javac can't include javax.annotation.processing.Generated as I see it (and that is what the compilation error tells me). I should put up an example but the problem with that is that the annotation processor I have detects javax.annotation.processing.Generated isn't available (when JPMS is used) and just generates the source without it. To reproduce "the issue" I need to change the annotation processor to not do that check and always include the javax.annotation.processing.Generated (and release that to central). I first noticed this when just flipping back and forth between traditional class path compilation (no module-info) and JPMS compilation (has module-info) and noticing the @Generated wasn't there in the generated source when there was a module-info. At this stage I'm pretty comfortable that the annotation processor can't include the javax.annotation.processing.Generated in the generated source with JPMS which is ok. Cheers, Rob. On Mon, 2 Nov 2020 at 23:02, Alan Bateman <alan.bate...@oracle.com> wrote: > On 02/11/2020 00:02, Rob Bygrave wrote: > > *> Since the type javax.annotation.processing.Generated has source * > > > > > > * retention only, there are no @javax.annotation.processing.Generated > > annotations in any class files compiled from source code emitted by your > > processor* > > > > > > The annotation processor generates *source code*. It does not generate > byte > > code. In this source generation case it does not seem to matter that the > > annotation is retention source - it will not compile but result in > > compilation errors [package javax.annotation.processing is not visible]. > > > > That is, with tooling of maven (and intellij) both do not compile the > > generated source that includes javax.annotation.processing.Generated > > without java.compiler being added to the *project module path*. It is not > > sufficient that requires java.compiler; is in the module-info of the > > annotation processor. > > > > When the annotation processor generates java source code that includes > > javax.annotation.processing.Generated and when this generated source is > > compiled it fails to compile with compilation errors like:. > > > > > > [ERROR] /<my generated source file>.java:[4,24] package > > javax.annotation.processing is not visible > > [ERROR] (package javax.annotation.processing is declared in module > > java.compiler, but module example does not read it) > > > > > > I believe the generated source is compiled along with the rest of the > > project source code using the *projects module path* which should not > > include the java.compiler module. > > > > To me this compile error is correct and reasonable. I think it's telling > > me that the generated source should only include things that are in the > > project module path (and java.compiler is not in the project module > path). > If I read your mails correctly then there are three invocations of javac > here. > > The first is to compile the annotation processor that is module > io.avaje.inject.generator. Its module declaration `requires > java.compiler` and `provides javax.annotation.processing.Processor with > ...`, all good. > > The second compilation is done with module io.avaje.inject.generator on > the processor module path (--processor-module-path). This generates a > source file with @javax.annotation.processing.Generated in the source > file. It sounds like this is working. > > I think the third compilation is compiling the generated source file. > Your first mail suggests that it is not compiled into a named module (no > module-info.java). This should work as all modules that export an API > are resolved. However the compiler error that you show above looks like > it is arises when compiling module "example". Is that a surprise? The > error suggests that the module declaration for module example doesn't > have `requires static java.compiler` so maybe the issue you are running > into is in the POM or a tooling issue? > > -Alan >
