[RFE] Control Relative Path Resolution
Alan.Bateman at oracle.com
Wed Feb 13 11:02:11 UTC 2019
On 12/02/2019 20:18, Robert Scholte wrote:
> Assuming this can be solved without forcing a new JVM to start, we
> need something like
> File f = new File( System.property( "file.basedir", ""), "a/b/c" );
> Here it is explicit done by the developer, but I would like to see it
> implicit, where the System.property( "file.basedir", "") is added by
> the java.io.File implementation in case the File is relative. To me
> explicit and implicit have the same result, hence I prefer implicit.
> This will remove the boiler template and it introduces a predefined
> name for the property, so that tools, IDEs and execution frameworks
> don't have to decide which property to choose.
> This should keep the behavior as (un)reliable as it used to be, but
> with the extra property you can give control and responsibility to the
> Another conclusion could be that new File( System.property(
> "file.basedir", ""), "a/b/c" ) will never work due to the
> multithreading issue.
> I don't know how this is implemented in Surefire, but what I do know
> is that I can't remember seeing issues about this over the last
> decade: adjusting the user.dir has worked for us for a long time (as
> this was the only way to adjust the relative path resolution)
It has always been unpredictable; some APIs picked up the new value,
some used the value from startup, others assume the working directory
I don't think introducing something like "file.basedir" will do anything
except bring back all the problems with user.dir. Even without
multi-threaded concerns it just takes one component to cache a relative
file path to bring back the same problems.
For tests that need to reach into src or test directories then it might
be best to make those locations available as system properties. That
will make it easier to write tests without concern as to whether they
are run in a single or multi-module project.
More information about the jdk-dev