RFR: 8300916: Re-examine the initialization of JNU Charset in StaticProperty [v9]

[Alan Bateman]

On Thu, 26 Jan 2023 00:19:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This issue was found during the review of this PR: https://github.com/openjdk/jdk/pull/12132 where `Charset` class was loaded/initialized at the phase 1 of the startup process. Since `Charset` depends on `StaticProperty`, loading of `Charset` class should be delayed. I basically moved cache for `jnuCharset` into the actual calling locations `ProcessImpl` and `ProcessEnvironment` for unix platforms so that initPhase1() won't initialize `Charset` class.
>> Unrelated, but I replaced `Locale.ENGLISH` with `Locale.ROOT` in the argument of `toLowerCase()`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert the permission check

Thanks for the updates/iterations, I think you've got this to a good place.

One thing to think about is having System.initPhase3 read file.encoding and if not UTF-8, it could call Charset.defaultCharset and if not the expected value then it could emit a warning like is done for a bad value of java.io.tmpdir.

One thing is whether to add a regression test to ensure that the default charset is UTF-8 when run with -Dfile.encoding=XXX and XXX is in the the service provider module.

Also, just thinking about diagnosability and whether there is any merit to have

src/java.base/share/classes/java/nio/charset/Charset.java line 632:

> 630: 
> 631:     @Stable
> 632:     private static Charset defaultCharset;

Style wise, I think the annotation is added between the private and static modifiers in other places.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12171