On Wed, 22 Feb 2023 17:52:01 GMT, Naoto Sato <na...@openjdk.org> wrote:
>>> curious - what scenario triggers this call at initLevel < 1 ? >> >> It's not supported, but it is possible that someone might run with >> -Dfile.encoding=GB18030, in which case the default charset is used before >> the system properties are initialized in initPhase1. Checking the init level >> breaks the circularity, the only downside is that can't switch to >> GB18030-2000 at the same time. > > `Charset` class is initialized *before* system properties are set up, in > order to check the JNU encoding (used for file path name) is a supported > charset or not. In some OS environments, GB18030 is the native encoding so we > need to avoid checking the system property in such a case. `@Stable` semantics are still fuzzy to me but the rule I've adhered to is that back to back stores to the field - if unavoidable - needs to be idempotent since the JIT (or AOT) may record any non-null value as a compile time constant at any time. I'd write this to not update the static field if initLevel() < 1. Such calls should be rare and only happen once on a system that has GB18030 as their native encoding. ------------- PR: https://git.openjdk.org/jdk/pull/12518