Signature of MethodHandleInfo.reflectAs is not specific enough
Ali Ebrahimi
ali.ebrahimi1781 at gmail.com
Sat Mar 1 02:17:52 PST 2014
Hi,
On Sat, Mar 1, 2014 at 12:16 AM, John Rose <john.r.rose at oracle.com> wrote:
> On Feb 25, 2014, at 3:13 AM, Ali Ebrahimi <ali.ebrahimi1781 at gmail.com>
> wrote:
>
> I know, this is too late, but I want to share my suggestion:
>
> public <T extends AccessibleObject&AnnotatedElement> T reflectAs(Class<?
> super T> expected, MethodHandles.Lookup lookup)
>
>
> Isn't this the same as
>
> public <T extends AccessibleObject> T reflectAs...
>
Oh, sorry, this is my bad.
I mean this:
public <T extends AccessibleObject&Member> T reflectAs(Class<? super T>
expected, MethodHandles.Lookup lookup)
>
> I think we considered AccessibleObject but rejected it as not buying
> anything significant compared with Member which is an interface.
>
> Perhaps
>
> public <T extends Member & AnnotatedElement> T reflectAs...
>
I considered this case, but unfortunately compiler accepts following test
case with this signature:
String ss = reflectAs(String.class, MethodHandles.lookup()); //OK!!!!!!!
This seams as compiler bug, any way with <T extends
AccessibleObject&Member> compiler catches error.
Finally, one case that compiler accepts with both signature is:
Object mo = reflectAs(Object.class, MethodHandles.lookup());
Maybe I'm wrong for this, Dan Smith can better interpret this.
T inferred to Object and T is not within its bound
(AccessibleObject&Member).
Regards,
Ali Ebrahimi
More information about the lambda-dev
mailing list