On Mon, 19 May 2025 12:15:38 GMT, David Beaumont <[email protected]> wrote:
>> Adding read-only support to ZipFileSystem.
>>
>> The new `accessMode` environment property allows for readOnly and readWrite
>> values, and ensures that the requested mode is consistent with what's
>> returned.
>>
>> This involved a little refactoring to ensure that "read only" state was set
>> initially and only unset at the end of initialization if appropriate.
>>
>> By making 2 methods return values (rather than silently set non-final fields
>> as a side effect) it's now clear in what order fields are initialized and
>> which are final (sadly there are still non-final fields, but only a split of
>> this class into two types can fix that, since determining multi-jar support
>> requires reading the file system).
>
> David Beaumont has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Fixed test.
test/jdk/jdk/nio/zipfs/NewFileSystemTests.java line 208:
> 206: // Multi-release JARs, when opened with a specified version are
> inherently read-only.
> 207: Path multiReleaseJar = createMultiReleaseJar();
> 208: try (FileSystem fs = FileSystems.newFileSystem(multiReleaseJar,
> Map.of("accessMode", "readWrite"))) {
I wonder if the ZIP filesystem implementation should throw an exception in this
case. In the case where the application code has explicitly stated
`accessMode=readWrite`, if the underlying file `Path` isn't writable, then we
currently throw an `IOException`. I think we should specify and implement the
same for the case where `accessMode=readWrite` and the file is a multi-release
JAR file.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2095637058
