Annotated Type bugs in OpenJDK 8

[David Holmes]

Probably better discussed on core-libs-dev - cc'd.

David

On 26/02/2015 4: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
>