On Thu, 20 Feb 2025 22:20:04 GMT, Brian Burkhalter <b...@openjdk.org> wrote:
>> Update the specification of `java.io.File.exists()` to match its behavior,
>> which seems correct in the context of how the empty abstract pathname is
>> documented elsewhere in the class.
>
> Brian Burkhalter has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains eight commits:
>
> - 8024695: Move getCWD to holder; remove Order from test
> - Merge
> - 8024695: Extend and clean up test
> - 8024695: Fix merge error; improve get*Space tests
> - Merge
> - 8024695: Add test of length()
> - 8024695: Change implementation to work for empty path
> - 8024695: new File("").exists() returns false whereas it is the current
> working directory
Looks like the [description of the
PR](https://github.com/openjdk/jdk/pull/22821#issue-2749006501) should be
updated now - we're no longer updating the specification to match the existing
behaviour?
src/java.base/unix/classes/java/io/UnixFileSystem.java line 37:
> 35:
> 36: private String getPathForSysCalls(String path) {
> 37: return path.isEmpty() ? getCWD().getPath() : path;
The Windows implementation has a guard for path == null. Is it superfluous
there, or should it be added here?
private String getPathForWin32Calls(String path) {
return (path != null && path.isEmpty()) ? getCWD().getPath() : path;
}
-------------
PR Comment: https://git.openjdk.org/jdk/pull/22821#issuecomment-2674268301
PR Review Comment: https://git.openjdk.org/jdk/pull/22821#discussion_r1965296464
