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.lev...@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 <fo...@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
>>
>
>
>
> _______________________________________________
> mlvm-dev mailing
> listmlvm-...@openjdk.java.nethttp://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
