On Tue, 31 Mar 2026 08:28:47 GMT, Paul Hübner <[email protected]> wrote:
>> Good to know. So `@Stable` is only useful for non final fields. >> >> Is the reason that the box caches `cache` fields are not final, (and >> `@Stable` instead)? Some AOT / CDS interaction? > > There are some inconsistencies. For instance, Integer sees its `cache` as > non-final, so I think a `@Stable` makes sense there given that the setup is > performed outside of the static initializer. It's not immediately clear to me > why this decision was made, but this is also how it is in mainline. > > Moving forwards, I propose: > * Ensure all `cache` variables are consistent with mainline and either > `static final` or `@Stable static`. > * If in preview, `static final` caches with `null` and `@Stable static` > caches with an empty array. > * Remove `isEnabled`. > * Revert changes in `valueOf`, i.e., call `PreviewFeatures`. > > Thoughts? On mainline Integer's cache is not final because the archived data may be invalid and need to be thrown away if a system property is changed. (This has always been the biggest headache with AOT) @xmas92 I think only `IntegerCache.cache` is non-final `@Stable`. Others seem to be final `@Stable`. A final `@Stable` is meaningful for arrays because a read of such an array element is considered a compiler constant if it is non-zero/null. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/2249#discussion_r3016335606
