<i18n dev> RFR: 8301119: Support for GB18030-2022 [v2]

[Alan Bateman]

On Thu, 23 Feb 2023 08:55:08 GMT, Claes Redestad <redestad at 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