On 01.04.2018 05:00, David Holmes wrote:
On 1/04/2018 11:13 AM, Jochen Theodorou wrote:
On 01.04.2018 01:51, David Holmes wrote:
[...
Anonymous inner class able to call private method in enclosing class
directly using method handles and no helper methods
...]
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).
What really surprised me was that I was able to use the anonymous
inner class as receiver for the handle I created from the surrounding
class and still got a successful call. Sure, when I think about an
unqualified
You should not be able to call a method of the enclosing class on an
instance of the inner class (unless there is also a subtype relationship
there). But there have been some oversights in that area which have been
fixed more recently (8u131, 9+).
I tried that with 9.0.4, and no, there is no subtype relationship.
method call in an inner class being able to call to an outer class
method, then this kind of behaviour makes sense. But having had to do
with Reflection before and knowing the bytecode side and what javac
usually generates I was really surprised about this. Ok, I was
actually already surprised about the lookup object of the inner class
allowing me to findSpecial that private method of the outer class, but
that I explained already. I am only not sure if this still qualifies
as "same accesses as the language permits". Maybe I am overthinking
here, because I always have trouble to look at code without seeing it
from the perspective of the compiler. And for the java compiler it is
more a question about choosing the right receiver, which it can do at
compile time. Thus it seems not to be necessary to have this. With
Java9 qualifying a lot of things I did do normally as a "you should
not do this and we actively prevent you from doing this now" I got a
bit more careful with unexpected features.
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.
If this is the expected behaviour for a current JDK8 and newer I am fine.
seems it is not for the invocation... but at least for the lookup object
this seems to be, which helps a lot already
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).
which means in the future I can do something like this in an inner class?
enclosingClass.getDeclaredMethod("somePrivateMethod").invoke(innerClassInstance)?
right now I would have to use setAccessible and the enclosing class
instance to make this work.
You won't need to use setAccessible. But the receiver must still be an
instance of the class whose method you are invoking.
ok, got it. Thx
bye Jochen
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
