Do package-infos need to be reset between annotation processing rounds?

[Jonathan Gibbons]

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>