On Wed, 21 May 2025 23:30:18 GMT, David Beaumont <d...@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: > > 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