Annotated Type bugs in OpenJDK 8

[Alex Buckley]

// compiler-dev is the correct list. type-annotations-dev is defunct.

Regarding JDK-8057804, I agree that AnnotatedParameterizedType deserves 
a getAnnotatedOwnerType() method. Since adding this method involves 
changing the Java SE API, it will need to target JDK 9 and appear in the 
compatibility notes.

As a practical matter, it is extremely unlikely that there now exist 
non-JDK implementations of AnnotatedParameterizedType, so I would go 
ahead with option 1 (no default method). However, Joe may have a 
different view (though the experience of adding default methods to Core 
Reflection in Java SE 8 did not turn out quite as expected, IIRC).

Alex

On 2/25/2015 11:00 AM, Jonathan Gibbons wrote:
> Forwarding to compiler-dev and type-annotations-dev
> bcc: jdk8u-dev
>
> And yes, the right people are seeing this message.
>
> -- Jon
>
>
> On 02/25/2015 10:02 AM, Joshua Humphries wrote:
>> Hey, all,
>> I'm want to contribute some fixes to JDK 8 Updates related to annotated
>> types in core reflection.
>>
>> After much pain, I finally got it to build on my Macbook. So now I'm
>> ready
>> to tackle a patch. The issues I plan to address in this patch follow:
>>
>>     - JDK-8057804 <https://bugs.openjdk.java.net/browse/JDK-8057804>
>>     - JDK-8057898 <https://bugs.openjdk.java.net/browse/JDK-8057898>
>>     - JDK-8058202 <https://bugs.openjdk.java.net/browse/JDK-8058202>
>>     - JDK-8066967 <https://bugs.openjdk.java.net/browse/JDK-8066967>
>> (marked
>>     resolved as a dup of the one above, JDK-8058202, but really is
>> *not* a
>>     dup)
>>
>> I actually filed all of these back in September. Unfortunately, since I'm
>> not an OpenJDK author, I can't login and add more comments to any of thee
>> bugs or interact with the assignee through the bug dashboard :(
>>
>> They are all assigned to Joel Borggrén-Franck -- so I hope you're on this
>> list and see this, Joel :)
>>
>> The biggest change is JDK-8057804
>> <https://bugs.openjdk.java.net/browse/JDK-8057804>, so I wanted to
>> discuss
>> options of how to address it.
>>
>> To summarize: there is a glaring omission in the
>> java.lang.reflect.AnnotatedType interfaces: there is *no way* to get
>> to the
>> annotations on a (non-static, inner) parameterized type's owner.
>>
>> The AnnotatedParameterizedType interface really *should *have a method
>> such
>> as:
>>     AnnotatedType getAnnotatedOwnerType();
>>
>> Without it, there is *no way* to use core reflection to examine
>> annotations
>> on the owner type. Such annotations are allowed, included in the class
>> file
>> by the compiler, and available via the model and annotation mirror APIs
>> used by annotation processors. But they aren't available via core
>> reflection.
>>
>> I've experimented with adding this method, and I have things working in a
>> local development environment. But there are some nasty implications to
>> adding a method to an interface. I think there are three approaches that
>> can be taken:
>>
>>     1. Add the method to the interface. Do not supply a default
>>     implementation (e.g. break compatibility). This would be very
>> similar to
>>     the action taken in Java 8 to add the #getAnnotatedBounds() method
>> to the
>>     TypeVariable interface. (Related: JDK-8062794
>>     <https://bugs.openjdk.java.net/browse/JDK-8062794>)
>>        - If such an incompatible change were deemed acceptable, it is
>>        unlikely that it would be done in a point release. So, if this
>> is the right
>>        solution, it would probably need to be implemented in the JDK 9
>> project
>>        instead of the JDK 8 Updates project
>>     2. Add the method to the interface. Supply a default
>> implementation for
>>     backwards compatibility.
>>        - A "best effort" implementation could grab the corresponding
>>        ParameterizedType's owner and wrap it an AnnotatedType that has no
>>        annotations. But then we're quietly suppressing the fact that
>> we've lost
>>        any annotations actually present.
>>        - Instead of supplying an incorrect implementation, perhaps a
>> better
>>        default would be to simply throw UnsupportedOperationException,
>> kind of
>>        like the default implementation added for Iterator#remove().
>>     3. Add a new interface that extends AnnotatedParameterizedType and
>> adds
>>     the method. This has the downside of polluting the namespace with
>> redundant
>>     interfaces, solely for trying to maintain compatibility. (No
>> future code
>>     should ever really use AnnotatedParameterizedType, so this feels
>> icky.)
>>
>> At the moment, I'm tempted to think that option #2 is the best, with the
>> default implementation being to throw.
>>
>> I was hoping for some feedback from folks on this list with goal of
>> arriving at a solution that would be accepted into the JDK 8 Update
>> project.
>>
>> ----
>> *Joshua Humphries*
>> joshua at bluegosling.com
>