jenkinsci/pipeline-groovy-lib-plugin#57 effectively does that—without jglick/pipeline-groovy-lib-plugin@b7bd774 you get Windows failures in one test: https://github.com/jenkinsci/pipeline-groovy-lib-plugin/runs/11808228071 which I could reliably reproduce locally on Windows 10, and also on Linux if I used file-leak-detector to assert that the lib JAR was not open at the end of the test. Theoretically it would be possible to write a JenkinsRule test here that fails (on Windows) without the hack but it would be pretty artificial since until jenkinsci/pipeline-groovy-lib-plugin#57 there would be no scenario (that I know of) in which Groovy sources are loaded from a JAR file.

openjdk/jdk#12871 also fixes the leak, though I think this override is still potentially helpful in that it bypasses the need to ever open the JAR file to begin with in two cases used by Groovy (checking for a content encoding and checking for a last modification time).

@jocwurs moving thread from f8b1e63#commitcomment-109435305: not sure how you got into this situation (are you @Grabbing Log4j or something?) but it sounds like org.apache.logging.log4j.core.config.ConfigurationSource is at fault.

@jglick yes we are grapbing a java library which contains log4j2. Still do not fully understand what is going wrong here.

@jocwurs looks like this is a known bug LOG4J2-3047, which has already been fixed as apache/logging-log4j2#1164. (BTW hi @jvz!) It may suffice to @Grab the fixed release explicitly before the library which pulls in a broken version.

@jglick thanks for the hint to this log4j bug. The library was using another log4j version than expected. It took the log4j lib coming from the analysis-model-api-plugin. And this version contains an older log4j (2.19.0).
BY shadowing log4j 2.20.0 I am now able to use the latest version of workflow-cps.
@uhafner maybe it is a good idea to update log4j used by analysis-model-api-plugin.