Vampire
commented
5 years ago Actually with IsolationMode.CLASSLOADER, it works fine, as then the classes are in a separate class loader and so the static fields don't influence each other.
I tried this with some breakpoint magic that that sets the isolation mode to CLASSLOADER after you have set it to PROCESS.
This of course also implicitly sets the fork mode to NEVER, so you loose the ability to specify custom JVM args and the max heap size but instead would need to do this on the Gradle daemon itself and to debug the execution you would debug the Gradle run itself. But at least then the runs are independent from each other.
Actually without refactoring SpotBugs you would probably need an even tighter isolation mode that combines CLASSLOADER within PROCESS so that the stuff gets a separate classloader in the worker daemon.
A working workaround that forces separate worker processes to be spawned is this:
tasks.withType(SpotBugsTask) {
doFirst {
jvmArgs "-DworkerUniquifier=${UUID.randomUUID()}"
}
}As it runs in the execution phase, it does not influence the cache key for the build cache or the up-to-date check, but if the task will be run due to out-of-dateness and cache-miss, it will get its own exclusive worker process as on each invocation the JVM args will be different and so a new process needs to be spawned.
KengoTODA
oehme
shevek
jscancella
SpotBugs uses static stuff which influences multiple runs and even builds for different projects and thus makes things different depending on situation and actually unpredictable.
Where I observed it is with spotbugs plugins as it gets pretty obviously and loudly displayed in this case, but there could of course be other and more subtle occurances that are not as obvious in effect.
Here two independent simple ways to reproduce the problem (simpler usage also triggers this, but with these instructions it should be 100% reproducible):
For all, add one or more spotbugs plugins, and make sure at least one bug will be found in each of the tasks run (somhow couldn't reproduce on first try without found bugs, didn't investigate why)
one task in multiple runs in the same daemon and same worker
gradlew --stopgradlew -i --daemon --max-workers 1 spotbugsMaingradlew -i --daemon --max-workers 1 spotbugsMainTrying to add already registered factorywarnings (if not, make sure that the last run had as one of its first linesStarting 2nd build in daemon)multiple tasks in one run even without daemon in the same worker
gradlew -i --no-daemon --continue --max-workers 1 spotbugsMain spotbugsTestspotbugsMainwill go like expectedspotbugsTestyou get a bunch ofTrying to add already registered factorywarningsThe cause here is, that the plugins are loaded with
DetectorFactoryCollection.instance().loadPlugin(plugin);into a static singleton, so if the same worker JVM is reused, the previously registered plugins are still there. Besides the harmless warning (as long as the settings are the same), this of course also means that the plugins stay loaded, even if a different build does not want them. This can happen with different SpotBugs tasks in the same project that are configured differently, but even worse it can happen with totally independent projects that are built in the same Gradle daemon where the SpotBugs tasks are run on the same worker JVMs.In case of the
DetectorFactoryCollection, it could maybe be worked around by usingedu.umd.cs.findbugs.DetectorFactoryCollection#resetInstance, but according to its documentation itis public for tests only!and maybe there are other stuff that is kept statically too.So I guess to fix this, either SpotBugs has to be refactored to not rely on static stuff or at least provide some means to reset all static stuff, or the isolation for the SpotBugs runner has to be increased, so that each SpotBugs run is done in its own forked JVM and not in reused worker JVMs. This will probably make the analysis a bit slower, but imho it is worth the wait if you in turn get more reliable, reproducable and expected results. The best would of course be the first option, to make SpotBugs properly work with different settings in the same JVM mutliple times, but as this is not a problem with "normal" SpotBugs usage per-se, I thought here might be the more appropriate place to report it.