Signature of MethodHandleInfo.reflectAs is not specific enough

[Ali Ebrahimi]

Hi,
I know this is not fully type safe, in fact java generics is not fully type
safe.
We don't have any better solution with current language support.
if we had:
<T extends A|B>
or
<T super R>
we had better solutions:
public <T extends Member | AnnotatedElement> T reflectAs(Class<T> expected,
Lookup lookup)

public <T extends Member & AnnotatedElement, R super T> R reflectAs(Class<?
super T> expected, Lookup lookup)

but we don't have such support in language.

But I think there is another solution that require change in j.l.r API
Make Member an AnnotatedElement

interface Member implements AnnotatedElement { ...}

and

public <T extends AnnotatedElement> T reflectAs(Class<T> expected, Lookup
lookup)





On Mon, Nov 11, 2013 at 10:44 AM, Peter Levart <peter.levart at gmail.com>wrote:

>  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 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
>>
>
>
>
> _______________________________________________
> mlvm-dev mailing listmlvm-dev at openjdk.java.nethttp://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/20131112/18b5822d/attachment.html