[PATCH] Prefer TMPDIR over hard coded /tmp

Robert Stupp snazy at snazy.de
Thu Apr 26 08:18:37 UTC 2018

> Right, it's come a few times. In principle it seems reasonable but it 
> will likely have a tail of issues. One concern is that it will cause 
> issues with the attach mechanism as that depends on the tool side 
> knowing the target VM's tmp dir. There's also the transition issue 
> where old JDKs will be using /tmp, new JDKs using whatever TMPDIR is 
> set too. This is one of these issues where most of the work will be 
> shaking out the knock on impact (that will be needed for the CSR and 
> release note at least).

I'm not sure, whether I understand the concern about the attach 
mechanism, as that seems to use the directory returned by 
which returns the hard coded "/tmp" for all Unix platforms (except 
MacOS). (No intention to change this.)

The concern about backward compatibility (app using a JVM with hard 
coded /tmp plus a JVM using TMPDIR) is absolutely correct. I'm just not 
sure whether that's actually (or usually) an issue for /tmp specifically 
(at least on Linux, 
http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s18.html). Well, at 
least if people actually use /tmp as it's supposed to be used, since 
/tmp could perfectly be a volatile filesystem, but it's actually on 
persistent storage, probably due to "misuse".

What I'm currently thinking of is, whether a JVM flag (-XX:+PreferTMPDIR 
or so, defaults to false) could be a compromise that preserves the 
current behavior and prevents issues with existing applications but 
gives people the option to use TMPDIR for java.io.tmpdir, if they want 
to. Using TMPDIR for java.io.tmpdir is mostly useful for building and 
testing code - i.e. having an easier way to use different locations for 
java.io.tmpdir instead of, for example, digging through build files and 
inspecting command lines to check, whether surefire/junit/testng/JMH 
passed the correct java.io.tmpdir properly to a spawned, maybe short 
lived, child JVMs. WDYT?


Robert Stupp

More information about the core-libs-dev mailing list