[RFE] Control Relative Path Resolution

[Alan Bateman]

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 
> tools/frameworks.
>
> 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 
cannot change.

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.

-Alan