Do package-infos need to be reset between annotation processing rounds?
jonathan.gibbons at oracle.com
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.
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:
> 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 .
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the compiler-dev