RFR: 8268192: LambdaMetafactory with invokespecial causes VerificationError [v2]

[Dan Smith]

On Tue, 8 Jun 2021 15:27:04 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

>> Small bug fix.
>
> Dan Smith has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up validation of implKind REF_invokeSpecial

src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java line 160:

> 158:                 // method with REF_invokeSpecial. Newer classes use REF_invokeVirtual or
> 159:                 // REF_invokeInterface, and we can use that instruction in the lambda class.
> 160:                 if (targetClass == implClass) {

The name `<init>` can't appear here. It's only used by `newInvokeSpecial`.

src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 189:

> 187:         // to invoke directly. (javac prefers to avoid this situation by
> 188:         // generating bridges in the target class)
> 189:         useImplMethodHandle = (Modifier.isProtected(implInfo.getModifiers()) &&

Switched from `!Modifier.isPublic` to `Modifier.isProtected`. Access errors from the caller Lookup should already be caught by validation when the `implementation` is cracked. Protected and `super` calls are the only cases where the access from the nestmate is not equivalent.

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

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