RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation [v2]

[Mandy Chung]

On Thu, 3 Jun 2021 20:40:23 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

>> Standardizes and better specifies the errors thrown by LambdaMetafactory, including for inputs that would not be generated by javac.
>> 
>> Does some renaming of core parameters/fields to better reflect their purpose.
>> 
>> In the implementation, stops using ACC_BRIDGE for any methods, which is not a good fit for what these methods do (they don't delegate to each other, but all invoke the same implementation method).
>
> Dan Smith has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix accidentally commented-out parts of test

src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java line 457:

> 455:      * @return a CallSite whose target can be used to perform capture, generating
> 456:      *         instances of the interface named by {@code factoryType}
> 457:      * @throws LambdaConversionException If {@code caller} does not have private

One additional comment:

The lookup access has been extended since 14 to include `MODULE` and `ORIGINAL` access.  
`Lookup::hasFullPrivilegeAccess` returns true if the lookup has `PRIVATE` and `MODULE` which means that this lookup is not teleported from another module via `Lookup::in` and `MethodHandles::privateLookupIn`.

What privilege do you expect the `caller` lookup should have?  I believe full privilege access is the appropriate privilege.  The `ORIGINAL` access is stricter as the lookup must be created from the original lookup class.

[1] shows what access a `Lookup` has when being produced via different APIs.

[1] https://download.java.net/java/early_access/jdk17/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#access-modes

-------------

PR: https://git.openjdk.java.net/jdk/pull/4346