On Tue, 24 Jan 2023 21:57:25 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: > > One more. The change to StaticProperty to avoid calling out to Charset.defaultCharset from the initializer is good. However, the other part to that is the scenario in PR 12132 where the default Charset was accidentally located via the provider mechanism in JDK 9-17. If I read the changes correctly, that fragile scenario will come back. We have a couple of ways to avoid that, one being to ensure that defaultCharset is called before the boot layer is set. A simpler, and more reliable, would be to change Charset.defaultCharset to use StandardCharsets.charsetForName with the value of "file.encoding", and avoid the provider lookup completely. ------------- PR: https://git.openjdk.org/jdk/pull/12171
