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

[Alan Bateman]

On Thu, 20 Feb 2025 03:15:39 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 incrementally with one additional commit since the last revision:
> 
>   8024695: Extend and clean up test

src/java.base/share/classes/java/io/File.java line 254:

> 252:     static File getCWD() {
> 253:         return CWD;
> 254:     }

This is a bit icky, have you looked at pushing this down to a holder class in UnixFileSystem and WinNTFileSystem so they they aren't dependent on this.

test/jdk/java/io/File/EmptyPath.java line 67:

> 65: 
> 66:     @Test
> 67:     @Order(1)

What is the reason for use `@Order` in these tests, is there a dependency? Asking because we've usually avoided need to do this and I'm trying to see if how someone might be able to add to this test in the future.

test/jdk/java/io/File/EmptyPath.java line 260:

> 258:         assertFalse(f.canRead());
> 259:         assertTrue(f.setReadable(true));
> 260:         assertTrue(f.canRead());

Need try-finally in the setter tests to ensure that the directory's permissions are restored in the event that the test fails.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22821#discussion_r1963023613
PR Review Comment: https://git.openjdk.org/jdk/pull/22821#discussion_r1963021549
PR Review Comment: https://git.openjdk.org/jdk/pull/22821#discussion_r1963020273