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

Gilles Duboscq gdub at openjdk.java.net
Fri Sep 11 15:07:23 UTC 2020


> [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 one additional commit since the last revision:

  Remove disableEagerInitialization concerns from BridgeMethod.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/93/files
  - new: https://git.openjdk.java.net/jdk/pull/93/files/422cd01d..625feb94

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=93&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=93&range=01-02

  Stats: 32 lines in 1 file changed: 0 ins; 22 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/93.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/93/head:pull/93

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


More information about the compiler-dev mailing list