JDK14 spec query : MethodHandles:dropLookupMode(int)

[Chris Hegarty]

Mandy,

> On 9 Mar 2020, at 18:55, Mandy Chung <mandy.chung at 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.