Signature of MethodHandleInfo.reflectAs is not specific enough

Ali Ebrahimi ali.ebrahimi1781 at
Mon Nov 11 01:24:56 UTC 2013

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 at> 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 at

More information about the core-libs-dev mailing list