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

Jaikiran Pai jpai at openjdk.org
Tue May 13 13:52:53 UTC 2025


On Mon, 12 May 2025 10:16:33 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:
> 
>   Fix comment based on current behaviour.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 167:

> 165:                     return null;
> 166:                 }
> 167:                 case String label when READ_WRITE.label.equals(label) -> {

I haven't yet fully caught up on the newer features of switch/case. Does this have any advantage as compared to the simpler:


case "readWrite" -> {
   return READ_WRITE;
}
case "readOnly" -> {
   return READ_ONLY;
}

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 174:

> 172:                 }
> 173:                 default -> {
> 174:                 }

Since we don't allow for any other value, I think moving the `throw new IllegalArgumentException` from outside of the switch into this `default` case might be suitable.

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

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


More information about the core-libs-dev mailing list