FindBugs GeneratedClassesJar task issues when run in parallel with the test task #75
Description
Running into a strange issue issue on versions of gradle-processors since v1.2.10 when the FindBugs GeneratedClassesJar task runs in parallel with the Gradle test task. Not sure if there's anything this plugin can reasonably do, but writing up in case there are any thoughts or ideas. Summarizing this in general terms since this is public Github, but happy to provide more details separately.
We basically have a standard internal service setup with "my-service-api" and "my-service-server" projects. "my-service-api" includes some classes generated through the immutables library which are used by "my-service-server". In more recent versions of the gradle-processors library, we see that our build fails with the JVM crash described in https://blogs.oracle.com/poonam/crashes-in-zipgetentry, which apparently happens when "a jar file being accessed has been modified/overwritten while the JVM instance was running."
From binary-searching versions, we're seeing that this happens starting in v1.2.10, due to the changes in the commit fb5d2f3 that adds the FindBugs GeneratedClassesJar task. The above crash seems to happen when the FindBugs GeneratedClasesJar runs in parallel with the unit tests for the server project. My guess is that it's the generated Java files from the immutables classes that are specifically hitting the above issue.
The workaround that we're successfully using for now is to require the FindBugs GeneratedClassesJar task to run after the tests, e.g. by including gradle statements such as:
tasks.getByPath("my-service-api:findbugsMainGeneratedClassesJar").mustRunAfter(":my-service-server:test")
tasks.getByPath(":my-service-api:findbugsTestGeneratedClassesJar").mustRunAfter(":my-service-server:test")
The direct causes seem to be the JVM bug listed above (and fixed in Java 9 in https://bugs.openjdk.java.net/browse/JDK-8142508) and the fragility of JVM class loading, but curious if there's anything that could be done to further defend against this (e.g. by sandboxing somehow).