On Thu, 26 Jan 2023 00:19:45 GMT, Naoto Sato <na...@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
