On Thu, 23 Feb 2023 08:55:08 GMT, Claes Redestad <[email protected]> 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
