This is another workaround: public <T extends Member&AnnotatedElement, R> R reflectAs(Class<? super T> expected, Lookup lookup);
info.reflectAs(Member.class, lookup);//works info.reflectAs(AnnotatedElement.class, lookup);//works info.reflectAs(Member.class, lookup);//works info.reflectAs(AnnotatedElement.class, lookup);//works info.reflectAs(Object.class, lookup);doesn't work. info.reflectAs(Other.class, lookup);doesn't work. with this does not need to your javadoc and is more type safe. . On Mon, Nov 11, 2013 at 1:59 AM, Remi Forax <fo...@univ-mlv.fr> wrote: > 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 > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
