Weird behaviour of relative Path objects in daemon mode

Help/Discuss
1

There is some weird behaviour that I was wondering about. I have this Gradle task:

task testPaths {
  println System.getProperty('user.dir')
  println new File('x').getCanonicalPath()
  println file('x').getCanonicalPath()
  println new File('x').toPath().toAbsolutePath()
}

If I play with it this is what I get:

PS C:\dev\gradle-test> gradle --no-daemon testPaths
C:\dev\gradle-test
C:\dev\gradle-test\x
C:\dev\gradle-test\x
C:\dev\gradle-test\x
:testPaths UP-TO-DATE

BUILD SUCCESSFUL

Total time: 1.407 secs
PS C:\dev\gradle-test> gradle --daemon testPaths
C:\dev\gradle-test
C:\dev\gradle-test\x
C:\dev\gradle-test\x
C:\Users\Joan\.gradle\daemon\3.0\x
:testPaths UP-TO-DATE

BUILD SUCCESSFUL

Total time: 0.708 secs

When running in daemon mode Path behaves differently from everything else. I’ve seen people saying that file(...) should always be used instead of new File(...) for relative paths. However in that case it is a Path object that behaves weirdly. Furthermore - it appears that the working directory is not used as the base directory for the relative path.

I need to construct a Path object since I need it to run some 3rd party code in a Gradle task. I was able to come up with some hackish ways to do so. But can someone explain this behaviour to me?

This is what I am running on:

Groovy: 2.4.7
Ant: Apache Ant™ version 1.9.6 compiled on June 29 2015
JVM: 1.8.0_66 (Oracle Corporation 25.66-b18)
OS: Windows 10 10.0 amd64

2

Your tasks should not rely on the working directory, always use the Project.file() method. Otherwise, your build will behave differently depending on from which subproject it is invoked.

3

Yes, but the working directory is the same in both cases. So it must be something else that causes this.
Also - there are no subprojects involved whatsoever. The build.gradle is literally only those few lines.

P.S.
I tested this on Linux. There --daemon behaves the same way as --no-deamon. Could this be a Windows issue?

4

It might be an issue in the VM implementation on Windows not allowing us to overwrite the current working dir. JVMs are not required to support this. Always use Project.file() :slight_smile:

5

Ok, thanks! Got that.

For the record - if someone encounters this on Windows - getting an absolute path from a relative path works fine via an instance of the File class (which is what Project.file() returns). The same is not true for instances of the Path class.