RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode

[Mandy Chung]

On Wed, 9 Sep 2020 08:18:11 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.

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

> 213:             if (disableEagerInitialization) {
> 214:                 try {
> 215:                     return new ConstantCallSite(caller.findStaticGetter(innerClass, LAMBDA_INSTANCE_FIELD,
> invokedType.returnType()));

Nit: it'd be good to wrap this long line.  There are a couple long lines in this patch.

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

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