Signature of MethodHandleInfo.reflectAs is not specific enough

[Gernot Neppert]

Hmm, maybe I don't understand you correctly, but I can see no compelling
need to be able to do

"info.reflectAs(AnnotatedElement.class, lookup)",

as the method's spec clearly says that it will return one of the three
types known to implement java.lang.reflect.Member.
Those types all implement java.lang.reflect.AnnotatedElement, so you're on
the safe side if you apply such a cast to the return value.

That said, since we know that Java allows Annotations on all class members,
a possibly more consistent API would make j.l.r.Member extend
j.l.r.AnnotatedElement!

(Now that we have default methods, such a change could even be made without
breaking compatibility.)



2013/11/10 Remi Forax <forax at univ-mlv.fr>

> The is a stupid issue with the signature of MethodHandleInfo.reflectAs,
> j.l.r.Field, Method or Constructor implement two interfaces Member and
> AnnotatedElement, with the current signature, the code
>   info.reflectAs(Member.class, lookup)
> works but the code
>   info.reflectAs(AnnotatedElement.class, lookup)
> doesn't work.
>
> Because there is no way to do an 'or' between several bounds of
> a type variable, I think that the signature of reflectAs should be
> changed from :
>   public <T extends Member> T reflectAs(Class<T> expected, Lookup lookup);
> to
>   public <T> T reflectAs(Class<T> expected, Lookup lookup);
>
> and the javadoc should be modified to explain that a Member or
> AnnotatedElement are
> valid bounds of T.
>
> As a side effect, the signature of MethodHandles.reflectAs(Class<T>,
> MethodHandle)
> should be updated accordingly.
>
> There is a workaround, one can write:
>   (AnnotatedElement)info.reflectAs(Member.class, lookup)
> but it's at best weird.
>
> cheers,
> Rémi
>
>