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 <forax@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