Odd result with canonical paths with intermixed usage of java.io.File and java.nio.file.Files APIs (original) (raw)
Alan Bateman Alan.Bateman at oracle.com
Mon Dec 11 14:25:36 UTC 2017
- Previous message: Odd result with canonical paths with intermixed usage of java.io.File and java.nio.file.Files APIs
- Next message: important discovery about a probable refactoring in jvm or OS
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 11/12/2017 14:06, Jaikiran Pai wrote:
:
So a few related questions that I have are: 1. Is this inconsistency an expected behaviour or is this a bug? 2. If this is an expected behaviour, then would it be a better idea (as an application developer) to use Path.toRealPath[2] instead of using the File.getCanonicalPath()? Are these 2 APIs semantically equivalent? The File.getCanonicalPath() talks about the canonical path being "unique" paths but the Path.toRealPath has no such mentions. The correctness issues with the canonicalization cache is a long standing issue [1]. You can workaround it by running with -Dsun.io.useCanonCaches=false as I think you have found. The goal is to eventually disable and remove it. The first steps to get there happened in JDK 9 when FilePermission was changed to not canonicalize by default (FilePermission was the original motivation for this cache).
If you have follow-up questions then please bring the thread to core-libs-dev.
-Alan
[1] https://bugs.openjdk.java.net/browse/JDK-7066948
- Previous message: Odd result with canonical paths with intermixed usage of java.io.File and java.nio.file.Files APIs
- Next message: important discovery about a probable refactoring in jvm or OS
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]