On 1/04/2018 2:47 AM, Jochen Theodorou wrote:
Hi all,
I just noticed something I would like to know if that is correct and as
specified (before I start using that in my application logic) using java
9.0.4
public class Application {
public Lookup foo() {
Supplier<Lookup> s = new Supplier<Lookup>() {
public Lookup get() { return MethodHandles.lookup); }
}
return s.get();
}
}
what I noticed is that the lookup object returned by the call to foo is
one with full access rights for the inner class of Application, but it
seems I am also having full access rights on Application itself. I can
for example call a private method in Application using a handle created
using this lookup object.
Is this really as intended? I am asking because Java would realize this
afaik with a helper method (at least in the past).
Was this always possible with MethodHandles, or did this change?
The Java language has always permitted this. But at the source level it
is achieved through helper methods as the VM does not allow it (yet).
Core reflection does not allow it (but by spec should). But
MethodHandles went to a lot of trouble to allow the same accesses as the
language permits (though sometimes needing to use special mechanisms
like Lookup.in). I can't say for sure MH has "always" allowed this
(sometimes the implementation has lagged when it comes to private method
access, particularly when private interface methods were introduced) -
though it would be easy to check.
Going forward, for JDK 11 we expect JEP 181 "Nestmates" to be in place,
which implements the language access semantics consistently across the
VM, MH and core reflection. So yes a nested type has full access to its
enclosing types, and full access to all other nested types in the same
nest (ie all types directly or indirectly nested in a given top-level
class).
Cheers,
David
bye Jochen
_______________________________________________
mlvm-dev mailing list
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