On Wed, 21 May 2025 23:30:18 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:
>
> More tweaking...
Looks like I'm late to the party :-) My apologies if this has already been
discussed a long time ago. My question is whether it's really necessary to
restrict the 'read-only' flag to existing ZIP files only. I don't see any issue
with allowing the creation of a new, empty ZIP file and marking it as
read-only. Sure, it might be useless since it's just an empty zip file system,
but that's up to the user. Not a very strong opinion though.
283 * <li>
284 * If the value is {@code "readOnly"}, the file system is
created
285 * <em>read-only</em>, and {@link
java.nio.file.FileSystem#isReadOnly()
286 * isReadOnly()} will always return {@code true}. Creating a
287 * <em>read-only</em> file system requires the underlying ZIP
file to
288 * already exist.
289 * Specifying the {@code create} property as {@code true}
with the
290 * {@code accessMode} as {@code readOnly} will cause an {@code
291 * IllegalArgumentException} to be thrown when creating the
ZIP file
292 * system.
293 * </li>
-------------
PR Comment: https://git.openjdk.org/jdk/pull/25178#issuecomment-2906012555
