Here is an updated webrev with an additional comment. Let me know if the comment can be improved or clarified.
http://cr.openjdk.java.net/~sla/7132199/webrev.01/ Thanks, /Staffan On 30 jan 2012, at 13:28, Staffan Larsen wrote: > On 30 jan 2012, at 12:23, Dmitry Samersoff wrote: > >> 1. Why we can't use System.getProperty("java.io.tmpdir") ? > > Since HotSpot and the tools run in separate processes it is important that > the file is in a well-known global location. It cannot be in different > locations for different processes. Since java.io.tmpdir can be set on the > command line (which JPRT does), it can be different in the tools and in > HotSpot. > > HotSpot will always write the file to /tmp/.java_pidXXX regardless of the > value of java.io.tmpdir (see 7009828). Thus, the tools need to always look > there. > >> 2. If you decide to hardcode "/tmp" please, create a global constant for it. > > I don't agree that this would make the code easier to read or maintain. I > should, however, include a comment saying that the file is always in /tmp > regardless of the value of java.io.tmpdir. > > > On 30 jan 2012, at 12:49, David Holmes wrote: > >> I'm somewhat confused by this problem. 6938627 is the CR that changed from >> /tmp to use the java.io.tmpdir property, but that CR did not modify the >> files that you have modified - so what broke these files? > > 7009828 then changed HotSpot back to use /tmp always. I seems like this has > been going back and forth for a while… I don't really know the whole history. > >> Looking at your fix, wouldn't it be simpler to just set the static tmpdir to >> /tmp and leave the rest of the code as-is? Why do you stop looking in the >> cwd in addition to changing the tmp location? Is it because hotspot will >> never write it there? > > Changing the tmpdir static would be a smaller fix, but all the cwd code would > then remain. Yes, HotSpot never writes to cwd. > > Thanks, > /Staffan
