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 PlatformSupport->VMSupport.getVMTemporaryDirectory->JVM_GetTemporaryDirectory->os::get_temp_directory, 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 -- Robert Stupp @snazy
