RFR: 8255576: (fs) Files.isHidden() throws ArrayIndexOutOfBoundsException (unix) [v3]
Alan Bateman
alanb at openjdk.java.net
Sun Nov 1 09:13:55 UTC 2020
On Sat, 31 Oct 2020 20:10:18 GMT, Christian Stein <cstein at openjdk.org> wrote:
>> Thanks for the update, I think I would put an assertFalse around this because the current directory shouldn't be hidden.
>>
>> Creating a new VM that runs in a hidden directory is probably a stretch. I don't think it is strictly required here but don't object to reviewing any proposals if you are interested in spending time on it.
>
> I wrapped a "logical assertFalse" around the call -- there were already 32 cases of `assertTrue(! ...)` via https://github.com/openjdk/jdk/pull/952/commits/c27abeab3a38daf2ae5dc25894c8b966d9edfc58
>
> I want to defer such a check to a different issue. If there was a feature like "chroot(Path)", or a virtual file system that could be mapped to the default one so that Path("") resolves to a hidden working directory ... or something else that's better (and faster) than spawning a new VM.
This test pre-dates the use of TestNG support so had its own assertTrue. We could add an assertFalse but what you have is okay too as it's just one usage.
A chroot(Path) like API would break the assumption that the current directory doesn't change. Every relative path would locate a different file. So if we add a test, and I don't think it's too important, then it would need to launch a new VM. There is test lib infrastructure to support this. Historically, multi VM tests tended to have reliability issues, also they are significantly slower that tests that run "in-process".
-------------
PR: https://git.openjdk.java.net/jdk/pull/952
More information about the nio-dev
mailing list