Re: Signature of MethodHandleInfo.reflectAs is not specific enough

11 Nov 2013

      On 11/11/2013 02:24 AM, Ali Ebrahimi wrote:
...
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. .
Hm... it doesn't look very compile-time type-safe:

     String s = info.reflectAs(Method.class, lookup); // compiles !!!

IMO, I would rather remove the Class parameter altogether. It serves no 
purpose in the method implementation other than to perform a cast-check 
on the returned object. The method could simply be:

     public <T extends Member> T reflect(Lookup lookup);

This would not solve the problem Remi put forward. I.e. this would not 
compile:

     AnnotatedElement ae = info.reflect(lookup);

But with an explicit cast, It compiles:

     AnnotatedElement ae = (AnnotatedElement) info.reflect(lookup);

And compared to what we would have with Class parameter and loosened 
compile-time type-safety as per Remi's suggestion, it is still shorter:

     AnnotatedElement ae = info.reflectAs(AnnotatedElement.class, 
lookup); // this is longer!

A type-unsafe variant is possible too (I'm not advocating it):

     public <T> T reflect(Lookup lookup);

Now that Generalized Target-Type Inference 
<http://openjdk.java.net/projects/jdk8/features#101> is part of Java 8, 
using Class<T> parameters just as hints to the compiler is not needed in 
many cases. But if one needs to hint the compiler, explicit type 
parameters can be used as an escape hatch as always:

     Object o = info.<Method>reflect(lookup);

Regards, Peter
...
On Mon, Nov 11, 2013 at 1:59 AM, Remi Forax <forax@univ-mlv.fr 
<mailto: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 <mailto: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

Re: Signature of MethodHandleInfo.reflectAs is not specific enough

Peter Levart