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 <fo...@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 > >
