Closed ian-bertolacci closed 3 years ago
I think this is related to a few previous issues (both open and closed) #114 and #132. Not being a java/JMH/gradle expert (or even intermediate), I'm not sure if this caused by JMH, gradle, or jmh-gradle-plugin
This bug is fully demonstrated, and described in more detail in this repository which is specifically for demonstrating it: https://github.com/ian-bertolacci/jmh-update-bug
(excerpts from the readme)
When developing, I sometimes make lots of changes until I like what I have.
In JMH, using the jmh-gradle-plugin (https://github.com/melix/jmh-gradle-plugin), this causes an issue, but only when using the gradle daemon.
To be specific, if I run
gradle clean build jmh
, then later change a class that JMH uses as a benchmark source, then rungradle clean build jmh
again, this causes ajava.lang.IncompatibleClassChangeError
exception to be thrownIn the project, there is a benchmark definition source file
project/src/jmh/MyClassBenchmark.java
It has an internal factory class,FactoryA
.This is fine, but lets say I then add a different factory,
FactoryB
, which is perfectly valid Java code and is perfectly acceptable to JMH (ignoring developer taste or best practices).If working from a clean project, making the changes, and then running
gradle clean build jmh
is perfectly fine, and the project will build and the benchmark will run successfully.In contrast, if working from a clean project, first running
gradle clean build jmh
, then making the changes, and finally runninggradle clean build jmh
again, it will throw the java.lang.IncompatibleClassChangeError.This can be worked around by running gradle with
--no-daemon
, or by restarting all gradle daemons.The full output for this case (and can be found in
outputs/project_updated_after_gradle_invocation_broken.2.out
):