Bug on multi-module projects when java.lang.invoke.InnerClassLambdaMetafactory is JIT'd

[smola]

Preconditions:

• Multi-module Maven build with retrolambda in multiple modules.
• retrolambda-maven-plugin with fork=false
• JDK 8, tested with various versions, my most recent test used Oracle JDK 1.8.0_281-b09.

If java.lang.invoke.InnerClassLambdaMetafactory is JIT'd, the static final reference to dumper will be inlined in a PrivilegedAction anonymous class (at least that's my guess given the observed behaviour) and remain unchanged even when later retrolambda executions change the dumper variable with reflection. The relevant JDK code is the following:

https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/9a751dc19fae78ce58fb0eb176522070c992fb6f/jdk/src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L314-L320

In practice, that means that once that class is JIT'd, for example, after processing 1000 lambdas, further executions of retrolambda will write .class files to the output directory of the previous module.

Here's a repository to reproduce the problem: https://github.com/smola/retrolambda-jit-bug

In short: run ./repro.sh and you should see .class files from module2 written to module1/target/classes.

Workarounds:

• Use fork=true
• Use interpreter execution only (very slow): MAVEN_OPTS="-Xint" ./repro.sh

[smola]

My guess is that a proper solution for this will not be easy. Maybe fork=true should be the default when no agent is used and JDK 8 is the current JDK? Also, the Maven module could print a warning if fork=false and the current build is multi-module.