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

src/jdk.zipfs/share/classes/module-info.java line 277:

> 275:  *   <td>
> 276:  *       A value defining the desired read/write access mode of the file 
> system
> 277:  *       (either <em>read-write</em> or <em>read-only</em>).

This line is slightly confusing. Initially I thought `read-write` and 
`read-only` are the actual values that this environment property will accept. 
But further review suggests that the actual literals supported are `readOnly` 
and `readWrite` and this line here I think is trying to explain the supported 
semantics of the file system.

Perhaps we could reword this to something like:

>
> A value defining the desired access mode of the file system. A ZIP file 
> system can be created to allow for read-write access or read-only access.

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

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

Reply via email to