RFR: JDK-8198945: Invalid RuntimeVisibleTypeAnnotations for annotation on anonymous class type parameter

Werner Dietl wdietl at gmail.com
Thu Jul 12 02:28:37 UTC 2018

The webrev looks good to me (note that I'm not a reviewer).
Maybe `copyNewClassAnnotationsToOwner` should now be renamed to
`propagateNewClassAnnotationsToOwner` or something else that's more
I like the test set. Maybe instead of having so many static methods I
would instantiate AnonymousClassTest in main.

JDK-8207018 seems very related to the current issue, so it would seem
worth-while to fix it at the same time. I added a comment there.
On the other hand JDK-8207017 seems sufficiently different to require
a separate fix.

cu, WMD.

On Tue, Jul 10, 2018 at 8:44 PM Liam Miller-Cushon <cushon at google.com> wrote:
> On Fri, Jul 6, 2018 at 7:24 PM Werner Dietl <wdietl at gmail.com> wrote:
>> Does this sound good to you?
> Yes, I agree with your summary. Thanks for the corrections and clarifications.
> In particular I agree that speaking of 'duplicating' annotations is incorrect, 'propagating' seems to be a better word. Parts of the annotation structures are copied when propagating annotations from the anonymous class supertype to the new expression (e.g. the element value pair structure), but not the target_type or type_path.
> I updated the fix to only propagate annotations from the top-level supertype. For example, given `new @A Outer. @B Inner<@C Object>() {}` we propagate only `@B`. When the annotations are propagated an appropriate location is generated with one or more INNER_TYPE entries to place the annotation on the anonymous' class synthetic declaration type.
> Here's the latest webrev: http://cr.openjdk.java.net/~cushon/8198945/webrev.03/
> While continuing to investigate this I think I discovered a couple of related bugs:
> * https://bugs.openjdk.java.net/browse/JDK-8207017
> * https://bugs.openjdk.java.net/browse/JDK-8207018
> I can continue to iterate on the fix to try to fix those issues as well, but they might be distinct enough to be worth dealing with separately.


More information about the compiler-dev mailing list