Signature of MethodHandleInfo.reflectAs is not specific enough

[Ali Ebrahimi]

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 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 at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20131111/d81ac7a2/attachment.html