Moved this thread from discussions mailing list[1] to here. Comments inline.
On 11/12/17 7:55 PM, Alan Bateman wrote:
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
Thanks Alan. Given that the cache itself is being planned to be
eventually removed, that answers the main part of my question and I can
workaround this issue in a couple of ways (disabling the cache using
that system property is one way) in the application, till that time.
The only remaining part that I'm curious about is this:
> ... 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.
[1] http://mail.openjdk.java.net/pipermail/discuss/2017-December/004655.html
-Jaikiran
