[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
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
More information about the core-libs-dev
mailing list