RFR: 8350880: (zipfs) Add support for read-only zip file systems [v4]

[Jaikiran Pai]

On Thu, 15 May 2025 18:27:35 GMT, David Beaumont <duke at openjdk.org> 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 245:

> 243:                     : "The underlying ZIP file is not writable";
> 244:             throw new IOException(
> 245:                     "A writable ZIP file system could not be opened for: " + zfpath + "\n" + reason);

The JDK coding guidelines recommend excluding file paths from exception messages. So in this case the `zfpath` should be left out from the exception message. Additionally, I haven't seen us using newline characters in exception messages that we construct in the JDK code. So I think we should leave that out too. 

Given this, I think it might be simpler to just change this `if` block to something like:



if (...) {
    String reason = multiReleaseVersion.isPresent()
        ? "the multi-release JAR file is not writable"
        : "the ZIP file is not writable";

    throw new IOException(reason);
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2093192898