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

Liam Miller-Cushon cushon at
Wed Dec 6 02:24:36 UTC 2017

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> 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> 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]
>>> .compiler/share/classes/com/sun/tools/javac/processing/Javac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the compiler-dev mailing list