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

[Liam Miller-Cushon]

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> 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/Jav
>> acProcessingEnvironment.java#l1518
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171205/8a59793b/attachment.html>