Do package-infos need to be reset between annotation processing rounds?
Jonathan Gibbons
jonathan.gibbons at oracle.com
Wed Dec 6 07:48:14 UTC 2017
We'll need Joe "Mr Annotation Processing" Darcy to chime in here, but
the Filer is supposed to detect clashes, and prevent
overwriting/overriding symbols. That's definitely supposed to happen for
normal classes/interfaces; I could believe that package-info has been
overlooked, but I would expect it to follow the same guidelines.
-- Jon
On 12/5/17 6:24 PM, Liam Miller-Cushon wrote:
> Is overriding package-infos different or worse than overriding other
> symbols? I've seen a number of examples where the same source file was
> compiled multiple times and the earlier results ended up on the class
> path of the later compilations, so a processor-generated class was
> both on the class path and generated during the compilation. Making
> that an error would be a somewhat invasive breaking change. I agree
> that it should be discouraged, but I'm not sure it's worth making an
> error? (Unless there's something special about package-infos that I'm
> missing.)
>
> On Tue, Dec 5, 2017 at 6:09 PM, Jonathan Gibbons
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
> Generally, annotation processing is supposed to only create
> information where there was no information previously, so if a
> package had a package-info with annotations, it seems like it
> should be an error to override it with another package-info, with
> or without annotations.
>
> -- Jon
>
>
> On 12/05/2017 05:39 PM, Liam Miller-Cushon wrote:
>> Thanks! If an annotated package-info is loaded from the class
>> path, and then a processor generates a package-info that contains
>> no annotations, the reset is necessary. (The reset isn't
>> necessary if the new package-info is annotated, since the old
>> annotations get overwritten even if they weren't reset between
>> rounds.)
>>
>> On Tue, Dec 5, 2017 at 4:46 PM, Jonathan Gibbons
>> <jonathan.gibbons at oracle.com
>> <mailto:jonathan.gibbons at oracle.com>> wrote:
>>
>> Liam,
>>
>> What about the case where an annotation processor generates
>> the package-info.java file? Is that a case where it is
>> important to reinit the packge symbol correctly, so that the
>> newly generated code is read?
>>
>> -- Jon
>>
>>
>> On 12/05/2017 03:39 PM, Liam Miller-Cushon wrote:
>>
>> I have a question about the logic in
>> JavacProcessingEnvironment's treeCleaner that resets
>> package-info state between annotation processing rounds [1].
>>
>> JDK-8193037 describes an issue where package-infos loaded
>> from the classpath are reset by treeCleaner. Those
>> symbols doesn't get reinitialized correctly, and package
>> annotations are not visible during subsequent annotation
>> processing rounds.
>>
>> I wondered if the logic was only meant to apply to
>> package-infos being compiled from source in the current
>> compilation (similar to how module-infos are handle by
>> treeCleaner), but I'm having trouble understanding when
>> that logic is necessary. Commenting out
>> `node.packge.package_info.reset();` and
>> `node.packge.reset();` in treeCleaner doesn't break any
>> jtreg tests. Does anyone have examples where that code is
>> needed? I'd like to add a regression test to ensure the
>> fix for JDK-8193037 doesn't interfere with the original
>> purpose of that code.
>>
>> Thanks,
>>
>> [1]
>> http://hg.openjdk.java.net/jdk/jdk/file/a358ebcfacfb/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java#l1518
>> <http://hg.openjdk.java.net/jdk/jdk/file/a358ebcfacfb/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java#l1518>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171205/add13a66/attachment.html>
More information about the compiler-dev
mailing list