-
Bug
-
Resolution: Duplicate
-
P3
-
None
-
15
-
None
-
b20
Prior to hidden classes, lambda proxy classes are defined as VM anonymous classes. VM anonymous class has special access - same access as its host class. Hence LambdaMetafactory is able to support invokespecial method handle to invoke a member of a superclass or superinterface of the target class even if the lambda proxy class is not a subtype of the method handle being invoked.
When LMF was converted to use hidden classes, LMF will convert `invokespecial` to access a member of its nestmate to `invokevirtual` or `invokeinterface` for binary compatibility.
But `invokespecial` invocation on a superclass would crash with `VerifyError`. It's a regression. Since javac generates a bridge method, this issue may not expose in the wild.
The possible solution is:
a) change/clarify the contract of LambdaMetafactory (only certain invokeSpecial method handles are supported) or
b) fall back in those cases to direct MethodHandle invocation
When LMF was converted to use hidden classes, LMF will convert `invokespecial` to access a member of its nestmate to `invokevirtual` or `invokeinterface` for binary compatibility.
But `invokespecial` invocation on a superclass would crash with `VerifyError`. It's a regression. Since javac generates a bridge method, this issue may not expose in the wild.
The possible solution is:
a) change/clarify the contract of LambdaMetafactory (only certain invokeSpecial method handles are supported) or
b) fall back in those cases to direct MethodHandle invocation
- duplicates
-
JDK-8268192 LambdaMetafactory with invokespecial causes VerificationError
-
- Resolved
-
- relates to
-
JDK-8274848 LambdaMetaFactory::metafactory on REF_invokeSpecial impl method has incorrect behavior
-
- Resolved
-
-
JDK-8238358 Implementation of JEP 371: Hidden Classes
-
- Resolved
-