Annotated Type bugs in OpenJDK 8

Jonathan Gibbons jonathan.gibbons at
Wed Feb 25 19:00:06 UTC 2015

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 <>
>     - JDK-8057898 <>
>     - JDK-8058202 <>
>     - 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
> <>, 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
>     <>)
>        - 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

More information about the compiler-dev mailing list