On Thu, 23 Feb 2023 08:55:08 GMT, Claes Redestad <redes...@openjdk.org> wrote:
>> `@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. > > Scratch that: as it seems to be important that we don't switch after startup > then what this code is really reaching for is `static final` field semantics. > Since `StandardCharsets` might be loaded very early a holder class pattern > might be necessary: > > > isGB18030_2000() { return GB18030Properties.GB18030_2000; } > > private static class GB18030Properties { > private static final GB18030_2000 = init(); > private static boolean init() { > if (VM.initLevel() < 1) { > // Cannot get the system property yet. Assumes non-2000 > return false; > } > return > "2000".equals(GetPropertyAction.privilegedGetProperty("jdk.charset.GB18030")); > } > } Right, doing nothing for the initLevel < 1 case means that `-Dfile.encoding=GB18030 -Djdk.charset.GB18030=2000` would use version 2022 in early startup (JNU encoding init) and then switch to version 2000. Using a holder class seems a better idea than trying to coordinate concurrent writers. ------------- PR: https://git.openjdk.org/jdk/pull/12518