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

Jonathan Gibbons jonathan.gibbons at
Wed Dec 6 02:09:10 UTC 2017

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 <mailto:jonathan.gibbons at>> wrote:
>     Liam,
>     What about the case where an annotation processor generates the
> 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]
>         <>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the compiler-dev mailing list