RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode [v2]
Mandy Chung
mchung at openjdk.java.net
Thu Sep 10 16:36:51 UTC 2020
On Thu, 10 Sep 2020 15:23:14 GMT, Gilles Duboscq <gdub at openjdk.org> wrote:
>> [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the
>> jdk.internal.lambda.disableEagerInitialization system property to be able to disable eager initialization of lambda
>> classes. This was necessary to prevent side effects of class initializers triggered by such initialization in the
>> context of the GraalVM native image tool. However, the change as it is implemented means that the behaviour of
>> non-capturing lambdas depends on the value of `disableEagerInitialization`: when it is false (the default) such lambdas
>> are actually a singleton while when it is true, a fresh instance is returned every time. Programs should definitely
>> _not_ rely on reference equality since the Java spec does not guarantee it. However, in order to separate concern and
>> ease debugging such bad programs, `disableEagerInitialization` shouldn't influence the singleton vs. fresh instance
>> behaviour of lambdas in either direction.
>
> Gilles Duboscq has updated the pull request incrementally with three additional commits since the last revision:
>
> - Remove extra field test from LambdaTest6
> - Wrap long lines
> - Add deciated test in the jdk tests
test/langtools/tools/javac/lambda/lambdaExpression/LambdaTest6.java line 33:
> 31: * @compile LambdaTest6.java
> 32: * @run main LambdaTest6
> 33: */
This line was added by JDK-8232806 (https://hg.openjdk.java.net/jdk/jdk/rev/27c2d2a4b695).
I assume you want to move the test case for JDK-8232806 to test/jdk/java/lang/invoke? If so,
BridgeMethod.java should be looked at too.
-------------
PR: https://git.openjdk.java.net/jdk/pull/93
More information about the compiler-dev
mailing list