On Wed, 9 Sep 2026 18:11:04 GMT, Chen Liang <[email protected]> wrote:
>> Convert uses of `@Stable` on instance final non-array fields to >> `@TrustFinalFields`. This gives us a better approximation for what classes >> we wish to migrate to strict final later, and allows the default values in >> these final fields to be constant folded. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Chen Liang has updated the pull request with a new target base due to a merge > or a rebase. The incremental webrev excludes the unrelated changes brought in > by the merge/rebase. The pull request contains six additional commits since > the last revision: > > - No need for blank line in KeyValueHolder > - Dead imports > - Merge branch 'master' of github.com:openjdk/jdk into > fix/stable-instance-final > - Merge branch 'master' of github.com:openjdk/jdk into > fix/stable-instance-final > - Merge branch 'master' of https://github.com/openjdk/jdk into > fix/stable-instance-final > - Remove stable from instance final non-array fields src/java.base/share/classes/java/util/zip/ZipFile.java line 96: > 94: // b) the list of cached Inflater objects > 95: // c) the Source object providing read access to the actual ZIP file > 96: private final CleanableResource res; This pre-existing `@Stable` on a non-array `final` field seems like an oversight. So removing `@Stable` either in this PR or separately I think is OK. As for introducing the `@TrustFinalFields` on `ZipFile`, my opinion is that we shouldn't introduce it. Constant folding at call sites of these final fields of `ZipFile` isn't a necessity, and as far as I can see, the only reason this class was chosen for `@TrustFinalFields` in this PR, was because it had a pre-existing `@Stable` field. Correct me if that wasn't the reason. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32773#discussion_r4047585177
