Update relativize method for java 9 #175
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I noticed the io spec was failing on my mac on jdk9 (but passing on
travis, which was running jdk 8). The relativize method arguably didn't
work correctly on pre jdk 9 jres (at least on osx). For example, I ran
the following in the console:
scala> import java.nio.file._
scala> val base = Paths.get("/foo/bar/..")
val base = Paths.get("/foo/bar/..")
base: java.nio.file.Path = /foo/bar/..
scala> val file = Paths.get("/foo/buzz")
val file = Paths.get("/foo/buzz")
file: java.nio.file.Path = /foo/buzz
scala> val relative = base.relativize(file)
val relative = base.relativize(file)
^
relative: java.nio.file.Path = ../../buzz
scala> base.resolve(relative).normalize
base.resolve(relative).normalize
^
res5: java.nio.file.Path = /buzz
This result is certainly not what I would expect. The fix is very easy,
just always normalize the paths (which is not very expensive, especially
compared to any file system operation).
eed3si9n
reviewed
Aug 2, 2018
| @@ -22,7 +22,7 @@ class IOSpec extends FlatSpec with Matchers { | |||
| val relativeRootDir = new File(nestedDir, "..") | |||
|
|
|||
| IO.relativize(rootDir.toFile, nestedFile).map(file) shouldBe Some(file("meh.file")) | |||
| IO.relativize(relativeRootDir, nestedFile).map(file) shouldBe Some(file("../../meh.file")) | |||
| IO.relativize(relativeRootDir, nestedFile).map(file) shouldBe Some(file("meh.file")) | |||
There was a problem hiding this comment.
So this changes the behavior from previous releases, but this looks better.
There was a problem hiding this comment.
Yeah. On jdk 9, this is what is returned even if normalize is not called in IO.relativize (which is how I found the issue in the first place). I'd be surprised if anyone was relying on the previous behavior.
|
A validation involving this pull request is in progress... |
|
Dbuild doesn't work with sbt 1.2.0, so the test result is nonsensical. |
eed3si9n
approved these changes
Aug 3, 2018
Merged
This was referenced Sep 27, 2018
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I noticed the io spec was failing on my mac on jdk9 (but passing on
travis, which was running jdk 8). The relativize method arguably didn't
work correctly on pre jdk 9 jres (at least on osx). For example, I ran
the following in the console:
scala> import java.nio.file._
scala> val base = Paths.get("/foo/bar/..")
val base = Paths.get("/foo/bar/..")
base: java.nio.file.Path = /foo/bar/..
scala> val file = Paths.get("/foo/buzz")
val file = Paths.get("/foo/buzz")
file: java.nio.file.Path = /foo/buzz
scala> val relative = base.relativize(file)
val relative = base.relativize(file)
^
relative: java.nio.file.Path = ../../buzz
scala> base.resolve(relative).normalize
base.resolve(relative).normalize
^
res5: java.nio.file.Path = /buzz
This result is certainly not what I would expect. The fix is very easy,
just always normalize the paths (which is not very expensive, especially
compared to any file system operation).