On Thu, 15 May 2025 18:27:35 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: > > Changes based on review feedback. src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 230: > 228: // It requires 'entryLookup' and 'readOnly' to have safe > defaults (which > 229: // is why they are the only non-final fields), and it requires > that the > 230: // inode map has been initialized. It's good to note that `determineReleaseVersion(...)` (and `createVersionedLinks(...)`) access instance fields of the `ZipFileSystem` being constructed. I think the comment however could be brief and should leave out the details about safe defaults. Perhaps something like: > determineReleaseVersion() and createVersionedLinks() access instance fields > while 'this' ZipFileSystem instance is being constructed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25178#discussion_r2093167748
