JDK-8001114 : Container annotation is not checked for semantic correctness
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 8
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2012-10-18
  • Updated: 2015-02-16
  • Resolved: 2012-12-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8 b69Fixed
Related Reports
Relates :  
JDK-7151010 - Add compiler support for repeating annotations
Description
The synthesized container annotation for repeating annotation instances is not checked for semantic correctness.

For example you may get a container that has a target incompatible with the declaration it is on.
Comments
verified in jdk8 b92
06-06-2013
The workaround is to update Symbols coming from class-files with a "best guess" default values to elements eary, then doing it properly at annotate time.
19-11-2012
The early checking of correctness introduces a second problem: The problem is basically the same as always: annotation queue ordering. In this case ClassReader (class file) symbols gets annotated after the repeat queue. And yes, I agree I'm not solving the real problem which would be annotation completion in general. So the problem is that I need to verify containers coming from ClassReader Symbols. By chance this has worked even if the symbols gets annotated after the repeating instance because the ClassReader (class-file) Symbols gets created with a state that while not final is good enough for me to work with (IE the proxys set up are good enough even though the get replaced later). Except for default values. As you can see a default value MethodSymbol is actually created to be deproxied later, so I set it on the Attribute for now, and rely on the deproxying to set it to its final value. I suspect there is no code relying on the fact that it must be null until it reaches its final deproxied value (which AFAICS is probably the same as the temporary MethodSymbol anyway).
19-11-2012