On Thu, 15 May 2025 18:27:35 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:
>
> Changes based on review feedback.
src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 241:
> 239: this.readOnly = forceReadOnly || multiReleaseVersion.isPresent()
> || !Files.isWritable(zfpath);
> 240: if (readOnly && accessMode == AccessMode.READ_WRITE) {
> 241: String reason = Files.isWritable(zfpath)
Nit - this additional call to Files.isWritable(...) can be avoided if we store
the value of the previous call (a couple of lines above). I realize that the
previous `Files.isWritable` is stashed at the end of the `||` conditionals to
prevent it from being invoked in certain situations.
So maybe a better change would be something like:
String reason = multiReleaseVersion.isPresent()
? "A multi-release JAR file opened with a specified version is not writable"
: "The underlying ZIP file is not writable";
which would then avoid any additional calls to `Files.isWritable`.
But I think this point may not be relevant for the reason I note below as a
separate comment.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2093180117
