RFR: 8024695: new File("").exists() returns false whereas it is the current working directory [v7]

[Daniel Fuchs]

On Thu, 20 Feb 2025 22:20:04 GMT, Brian Burkhalter <bpb at 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