Signature of MethodHandleInfo.reflectAs is not specific enough
mcnepp02 at googlemail.com
Mon Nov 11 09:55:48 UTC 2013
Hmm, maybe I don't understand you correctly, but I can see no compelling
need to be able to do
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
(Now that we have default methods, such a change could even be made without
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);
> 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>,
> should be updated accordingly.
> There is a workaround, one can write:
> (AnnotatedElement)info.reflectAs(Member.class, lookup)
> but it's at best weird.
More information about the core-libs-dev