I'm seeing this in LogbackLoggingSystemTests but it could happen in any test that sets java.io.tmpdir. The pollution happens like this:

  1. A test's setup code setsjava.io.tmpdir to a JUnit-provided temporary directory
  2. Some code, a call to Files.createTempFile for example, causes java.io.File.TempDirectory to be loaded and its tmpdir static is set to the value of java.io.tmpdir
  3. A test's cleanup code restores java.io.tmpdir to its original value and JUnit deletes its temporary directory
  4. Some code tries to use Files.createTempFile and it fails because java.io.File.TempDirectory.tmpdir points to the directory that was deleted in step 3

Ideally, we'd avoid setting java.io.tmpdir in our tests. Failing that, we could ensure that java.io.File.TempDirectory has been initialized before we set it so that its tmpdir static doesn't get polluted with a custom directory that may only exist for the duration of a single test.

There's a similar problem with java.nio.file.TempFileHelper.tmpdir that's used by java.nio.file.Files.createTempFile(String, String, FileAttribute<?>...)