P4
The construction of `ZipFileSystem` is somewhat complex, especially around multi-release JAR files. Several instance fields are non-final so they can be reset during construction from an initial default value to a "final" value.
However since this is done in helper methods called from the constructor, it's hard to track down and reason about when these are set, and whether the instance is ever used in an undefined state.
It also makes adding read-only support (see JDK-8350880) harder, because that needs to know if the multi-release version was set.
The proposal is to refactor a few parts of the constructor and associated helper methods so that all instance fields are set in the constructor rather than in helper methods.
This should be a zero impact change (identical functionality) and make future maintenance easier by making inter-dependence of instance fields explicit.
However since this is done in helper methods called from the constructor, it's hard to track down and reason about when these are set, and whether the instance is ever used in an undefined state.
It also makes adding read-only support (see JDK-8350880) harder, because that needs to know if the multi-release version was set.
The proposal is to refactor a few parts of the constructor and associated helper methods so that all instance fields are set in the constructor rather than in helper methods.
This should be a zero impact change (identical functionality) and make future maintenance easier by making inter-dependence of instance fields explicit.