Hi Dan,
Thanks for looking at this so quickly.
On 31/01/2018 12:19 AM, Daniel Heidinga wrote:
Thanks David.
These changes all seem reasonable. I was going to complain about
changing 'will occur' to 'may occur' as 'may' make makes it difficult to
determine when it will vs won't occur but I think it's correct in this case.
It's really non-normative anyway. The real process is described in JLS
15.12.4.4, so if you wanted to know for sure case-by-case then you'd
need to refer back to that.
David
-----
--Dan
----- Original message -----
From: David Holmes <david.hol...@oracle.com>
Sent by: "valhalla-spec-experts"
<valhalla-spec-experts-boun...@openjdk.java.net>
To: valhalla-spec-experts@openjdk.java.net
Cc:
Subject: API Updates: 8191116: [Nestmates] Update core reflection,
MethodHandle and varhandle APIs to allow for nestmate access
Date: Tue, Jan 30, 2018 4:55 AM
I've gone through the API specifications for core reflection,
MethodHandles and VarHandles to see what changes are needed to
accommodate nestmates and the related invocation rule changes. Turns
out there is very little needed and most of what there is is
non-normative, just correcting or clarifying particular things. For
VarHandle nothing is needed as it defers all access checking to
MethodHandle.Lookup.
Bug: https://bugs.openjdk.java.net/browse/JDK-8191116
<https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8191116&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=LBQnmyrHQkEBElM8bAxhzfwLG2HbsYDdzEznFrQoob4&m=PbzMXdwGz8_Tt-pH8pku2uAOgfXl4NIVy58_7jK3rRg&s=VWdi_YhjdK6C_lkCp3BfInxLR9CoDESlYiHUKD-F3_g&e=>
Webrev: http://cr.openjdk.java.net/~dholmes/8191116/webrev/
<https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Edholmes_8191116_webrev_&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=LBQnmyrHQkEBElM8bAxhzfwLG2HbsYDdzEznFrQoob4&m=PbzMXdwGz8_Tt-pH8pku2uAOgfXl4NIVy58_7jK3rRg&s=EAQJ2EaJNAHuSFbIwnMbVq-nbhvEnWugrV2t4KpDNbA&e=>
Core reflection changes:
These are minimal as core reflection already expresses all access
control in terms of "Java language access control" which already
allows for nestmate access.
- java/lang/reflect/AccessibleObject.java
* <p> Java language access control prevents use of private
members outside
- * their class; package access members outside their package;
protected members
+ * their top-level class; package access members outside their
package; protected members
This corrects the definition of private access in the Java language.
- java/lang/reflect/Method.java
* using dynamic method lookup as documented in The Java Language
- * Specification, Second Edition, section 15.12.4.4; in particular,
- * overriding based on the runtime type of the target object will
occur.
+ * Specification, section 15.12.4.4; in particular,
+ * overriding based on the runtime type of the target object may occur.
Removed unnecessary reference to "Second Edition". Changed 'will
occur' to 'may occur' to account for the different forms of
invocation that may apply.
MethodHandle API Changes:
- java/lang/invoke/MethodHandle.java
* A non-virtual method handle to a specific virtual method
implementation
* can also be created. These do not perform virtual lookup based on
* receiver type. Such a method handle simulates the effect of
- * an {@code invokespecial} instruction to the same method.
+ * an {@code invokespecial} instruction to the same non-private method;
+ * or an {@code invokevirtual} or {@code invokeinterface}
instruction to the
+ * same private method (as applicable).
I tried to clarify that non-virtual invocations are not limited to
invokespecial - as private invocations via invokevirtual or
invokeinterface are also non-virtual.
- java/lang/invoke/MethodHandles.java
* <p>
- * In some cases, access between nested classes is obtained by
the Java compiler by creating
- * an wrapper method to access a private method of another class
- * in the same top-level declaration.
+ * Since JDK 11 the relationship between nested types can be
expressed directly through the
+ * {@code NestHost} and {@code NestMembers} attributes.
+ * (See the Java Virtual Machine Specification, sections 4.7.28
and 4.7.29.)
+ * In that case, the lookup class has direct access to private
members of all its nestmates, and
+ * that is true of the associated {@code Lookup} object as well.
+ * Otherwise, access between nested classes is obtained by the
Java compiler creating
+ * a wrapper method to access a private method of another class
in the same nest.
* For example, a nested class {@code C.D}
Updated the nested classes description to cover legacy approach and
new nestmate approach.
- * {@code C.E} would be unable to those private members.
+ * {@code C.E} would be unable to access those private members.
Fixed typo: "access" was missing.
* <em>Discussion of private access:</em>
* We say that a lookup has <em>private access</em>
* if its {@linkplain #lookupModes lookup modes}
- * include the possibility of accessing {@code private} members.
+ * include the possibility of accessing {@code private} members
+ * (which includes the private members of nestmates).
* As documented in the relevant methods elsewhere,
* only lookups with private access possess the following
capabilities:
* <ul style="font-size:smaller;">
- * <li>access private fields, methods, and constructors of the
lookup class
+ * <li>access private fields, methods, and constructors of the
lookup class and its nestmates
Clarify that private access includes nestmate access.
- * access all members of the caller's class, all public types
in the caller's module,
+ * access all members of the caller's class and nestmates, all
public types in the caller's module,
Ditto.
* When called, the handle will treat the first argument as a
receiver
- * and dispatch on the receiver's type to determine which method
+ * and, for non-private methods, dispatch on the receiver's
type to determine which method
* implementation to enter.
+ * For private methods the named method in {@code refc} will be
invoked on the receiver.
Clarify dispatch process for private versus non-private.
* @throws IllegalAccessException if access checking fails,
* or if the method is {@code
static},
- * or if the method is {@code
private} method of interface,
This is the only actual spec change - it's no longer illegal for
findVirtual to be used to find a private interface method.
Thanks,
David
