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

[Jonathan Gibbons]

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/5a7f81fa/attachment-0001.html>