On Windows, if you open a file handle, you can never modify / delete / move that file until the file handle is given up.

Unfortunately, the java.util.jar.JarFile API is a big offender and creates a file handle on creation. It only gives up the handle if close() is called directly or via finalize().

If sbt is set up to use exportJars, and junit-interface is used (I've confirmed and isolated that the junit-interface must be present to trigger this bug), JarFile references are not closed and - for some inexplicable reason - forcing gc and runFinalizers doesn't trigger the finalizers to run (this is a well known "feature" of Java), as per sbt/sbt#1223 which seems to workaround similar bugs in the scala compiler itself, see https://issues.scala-lang.org/browse/SI-9632 and ensime/ensime-server#1322 (I'll give this an SI- soon).

Unfortunately, this is quite a serious bug.

It has the unfortunate side effect that the build tool can no longer delete any of the jars and compilation effectively becomes a no-op. I believe sbt may silently fail at this point, but I'm using some extremely loud customisations that check for failure https://github.com/fommil/sbt-big-project/blob/master/src/main/scala/BigProjectSettings.scala#L104

Others may have experienced this but it would have manifested itself in terms of the jar file not being updated.

In case it is relevant (I'm not sure it is), my project uses junit 4.11.0 and I depend on junit-interface intransitively.