Re: JDK14 spec query : MethodHandles:dropLookupMode(int)
I have bcc'ed jdk-dev and add core-libs-dev mailing list where this thread should be discussed. The spec says: "When dropping|PACKAGE|then the resulting lookup will not have|PACKAGE|or|PRIVATE|access.When dropping|MODULE|then the resulting lookup will not have|MODULE|,|PACKAGE|, or|PRIVATE|access. If|PUBLIC|is dropped then the resulting lookup has no access." @throws IAE if modeToDrop is a valid mode. I found the spec is quite clear that there is no condition to require the modeToDrop must exist. Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8226916 On 3/9/20 3:06 AM, Andrew Leonard wrote:
Thank you Mandy for raising the bug, I have one more query please, we may want to add to the bug that I am not sure about: *testDropLookupMode*() in test/jdk/java/lang/invoke/modules/m3/jdk/test/ModuleAccessTest.java:
public void testDropLookupMode() throws Exception { Lookup lookup = MethodHandles.privateLookupIn(m5.type1, m4.lookup); assertTrue((lookup.lookupModes() & MODULE) == 0); <--- MODULE doesn't exist ... Lookup lookup3 = lookup.dropLookupMode(MODULE); ---> assertTrue(lookup3.lookupModes() == (lookup.lookupModes() & ~(PROTECTED|PRIVATE|PACKAGE)));
Based on the expected result above, does it mean PRIVATE, PACKAGE should be dropped whether or not MODULE exists in the access mode (PROTECTED is dropped by default) ? If so, the document should be updated to explicitly clarify the exception case?
Thanks, Andrew
Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard@uk.ibm.com
Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Mandy,
On 9 Mar 2020, at 16:37, Mandy Chung <mandy.chung@oracle.com> wrote:
I have bcc'ed jdk-dev and add core-libs-dev mailing list where this thread should be discussed.
The spec says:
"When dropping PACKAGE then the resulting lookup will not have PACKAGE or PRIVATE access. When dropping MODULE then the resulting lookup will not have MODULE, PACKAGE, or PRIVATE access. If PUBLIC is dropped then the resulting lookup has no access."
@throws IAE if modeToDrop is a valid mode.
I found the spec is quite clear that there is no condition to require the modeToDrop must exist.
Sure, I guess it somewhat depends on how you see 8240242 [1] turning out. 8240242 clearly describes a similar(ish) issue where dropping PUBLIC, when it is not currently held, has no effect, i.e. it does not result in “no access” - this is either a bug in the implementation, or a bug/clarification in the spec. If the latter, then there are some scenarios where the outcome of passing a mode to dropLookupMode will have some dependency on the actual held modes. -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8240242
On 3/9/20 10:45 AM, Chris Hegarty wrote:
Sure, I guess it somewhat depends on how you see 8240242 [1] turning out. 8240242 clearly describes a similar(ish) issue where dropping PUBLIC, when it is not currently held, has no effect, i.e. it does not result in “no access” - this is either a bug in the implementation, or a bug/clarification in the spec. If the latter, then there are some scenarios where the outcome of passing a mode to dropLookupMode will have some dependency on the actual held modes.
The confusion here is the public lookup with UNCONDITIONAL mode. In JDK 9, a public lookup has PUBLIC and UNCONDITIONAL modes set whereas in 14 JDK-8226916 revises public lookup objects with only UNCONDITIONAL bit set. Here is the spec clarification I am thinking of that may explain why the focus is not whether MODULE bit is set or not. @@ -1524,14 +1524,20 @@ * Creates a lookup on the same lookup class which this lookup object * finds members, but with a lookup mode that has lost the given lookup mode. * The lookup mode to drop is one of {@link #PUBLIC PUBLIC}, {@link #MODULE - * MODULE}, {@link #PACKAGE PACKAGE}, {@link #PROTECTED PROTECTED} or {@link #PRIVATE PRIVATE}. - * {@link #PROTECTED PROTECTED} is always - * dropped and so the resulting lookup mode will never have this access capability. - * When dropping {@code PACKAGE} then the resulting lookup will not have {@code PACKAGE} - * or {@code PRIVATE} access. When dropping {@code MODULE} then the resulting lookup will - * not have {@code MODULE}, {@code PACKAGE}, or {@code PRIVATE} access. If {@code PUBLIC} - * is dropped then the resulting lookup has no access. If {@code UNCONDITIONAL} - * is dropped then the resulting lookup has no access. + * MODULE}, {@link #PACKAGE PACKAGE}, {@link #PROTECTED PROTECTED}, + * {@link #PRIVATE PRIVATE}, or {@code UNCONDITIONAL}. + * If this lookup has at least {@code PUBLIC} mode then + * {@link #PROTECTED PROTECTED} is always dropped and so the resulting lookup + * mode will never have this access capability. When dropping {@code PACKAGE} + * then the resulting lookup will not have {@code PACKAGE} or {@code PRIVATE} access. + * When dropping {@code MODULE} then the resulting lookup will not have + * {@code MODULE}, {@code PACKAGE}, or {@code PRIVATE} access. + * When dropping {@code PUBLIC} then the result lookup has no access. + * + * <p> If this lookup has {@code UNCONDITIONAL} mode, this lookup is a + * {@linkplain MethodHandles#publicLookup() public lookup} and it has no + * other mode set. When dropping {@code UNCONDITIONAL} on a public lookup + * then the resulting lookup has has no access. * Is this clearer? Mandy
Mandy,
On 9 Mar 2020, at 18:55, Mandy Chung <mandy.chung@oracle.com> wrote:
...
Here is the spec clarification I am thinking of that may explain why the focus is not whether MODULE bit is set or not.
@@ -1524,14 +1524,20 @@ * Creates a lookup on the same lookup class which this lookup object * finds members, but with a lookup mode that has lost the given lookup mode. * The lookup mode to drop is one of {@link #PUBLIC PUBLIC}, {@link #MODULE - * MODULE}, {@link #PACKAGE PACKAGE}, {@link #PROTECTED PROTECTED} or {@link #PRIVATE PRIVATE}. - * {@link #PROTECTED PROTECTED} is always - * dropped and so the resulting lookup mode will never have this access capability. - * When dropping {@code PACKAGE} then the resulting lookup will not have {@code PACKAGE} - * or {@code PRIVATE} access. When dropping {@code MODULE} then the resulting lookup will - * not have {@code MODULE}, {@code PACKAGE}, or {@code PRIVATE} access. If {@code PUBLIC} - * is dropped then the resulting lookup has no access. If {@code UNCONDITIONAL} - * is dropped then the resulting lookup has no access. + * MODULE}, {@link #PACKAGE PACKAGE}, {@link #PROTECTED PROTECTED}, + * {@link #PRIVATE PRIVATE}, or {@code UNCONDITIONAL}.
All six lookup modes are enumerated. Good.
+ * If this lookup has at least {@code PUBLIC} mode then + * {@link #PROTECTED PROTECTED} is always dropped and so the resulting lookup + * mode will never have this access capability. When dropping {@code PACKAGE} + * then the resulting lookup will not have {@code PACKAGE} or {@code PRIVATE} access. + * When dropping {@code MODULE} then the resulting lookup will not have + * {@code MODULE}, {@code PACKAGE}, or {@code PRIVATE} access. + * When dropping {@code PUBLIC} then the result lookup has no access.
I’m afraid this is still a little confusing to me ( but that could be just me! ).
+ * <p> If this lookup has {@code UNCONDITIONAL} mode, this lookup is a + * {@linkplain MethodHandles#publicLookup() public lookup} and it has no + * other mode set. When dropping {@code UNCONDITIONAL} on a public lookup + * then the resulting lookup has has no access.
The public lookup scenario is very clear. Just an idea; now that you have this new UNCONDITIONAL paragraph, it could be simpler to reorder things a little to build upon it. For example: /** * Creates a lookup on the same lookup class which this lookup object * finds members, but with a lookup mode that has lost the given lookup mode. * The lookup mode to drop is one of {@link #PUBLIC PUBLIC}, {@link #MODULE * MODULE}, {@link #PACKAGE PACKAGE}, {@link #PROTECTED PROTECTED}, * {@link #PRIVATE PRIVATE}, or {@code UNCONDITIONAL}. * * <p> If this lookup has {@code UNCONDITIONAL} mode, this lookup is a * {@linkplain MethodHandles#publicLookup() public lookup} and it has no * other mode set. When dropping {@code UNCONDITIONAL} on a public lookup * then the resulting lookup has has no access. * * <p> If this lookup is not a <i>public lookup</i>, then the following * applies regardless of the actual lookup modes held. * The {@link #PROTECTED PROTECTED} mode is always dropped and so the resulting lookup * mode will never have this access capability. When dropping {@code PACKAGE} * then the resulting lookup will not have {@code PACKAGE} or {@code PRIVATE} access. * When dropping {@code MODULE} then the resulting lookup will not have * {@code MODULE}, {@code PACKAGE}, or {@code PRIVATE} access. * When dropping {@code PUBLIC} then the result lookup has no access. * ... -Chris.
participants (2)
-
Chris Hegarty
-
Mandy Chung