Access Checking for MethodHandles.Lookup broken?

[Sebastian Sickelmann]

I am sorry. Due to a configuration failure in my IDE had run with 1.7.0_16

Checked this again with 1.7.0_45 and 1.8.0-ea-b109 and everything is fine.

Sorry for the mailing-list noise.

-- Sebastian

Am 22.11.2013 08:33, schrieb Sebastian Sickelmann:
> Hi,
>
> i found a strage behavior while using invokeDynamic and binding to field
> instances with findGetter and findSetter.
>
> See here for the code:
>
> https://github.com/picpromusic/incubator/tree/master/jdk/methodHandles
>
> There is a class BarBase with a private field and two classes
> - Bar (which extends BarBase)
> - Foo (which extends Bar)
>
> If i create a Lookup for the class Foo and lookup a field with the name
> of the private field of BarBase like this:
>
> fooLookup.findGetter(BarBase.class, "myPrivateField", int.class);
> I get an IllegalAccessException as expected.
>
> If i look it up with another searchRoot
> fooLookup.findGetter(Base.class, "myPrivateField", int.class);
> I also get an IllegalAccessException.
>
> A NoSuchFieldException would also be nice, but because this mimics the
> semantics of
> super.publicFieldInSuperClass versus this.publicFieldInSuperClass
> (yields to differend bytecodes) i can life with this minor glitch.
>
> But if i try to lookup the field with something like this:
> fooLookup.findGetter(Foo.class, "myPrivateField", int.class);
> I do not get an IllegalAccessException ( and as expected also no
> NoSuchFieldException).
> I even can access the field through this MethodHandle.
>
> Should i file a bug for this? Or is this intentional?
>
> I think it is a bug, and it look to me that it is in
> MethodHandleNatives.resolve where the field lookup is made through the
> hirachie but the access-check is done with the searchRoot (in this case
> Foo.class) ?
> I have not take a closer look to the native MethodHandleNative.resolve
> but i will in the near future and work toward a fix of this.
>
> -- Sebastian
>
>
>