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. src/java.base/unix/classes/java/lang/ProcessImpl.java line 74: > 72: // Cache for JNU Charset. The encoding name is guaranteed > 73: // to be supported in this environment. > 74: static final Charset JNU_CHARSET = > Charset.forName(StaticProperty.jnuEncoding()); Before the change in this PR, the `jnuCharset` used to fallback to `Charset.defaultCharset()`, if the `sun.jnu.encoding` value wasn't a legal charset or couldn't be loaded. On this line, we no longer do that. The comment, above this line, indicates that this is intentional. Looking at the code in `java.lang.System#initPhase1()`, the `sun.jnu.encoding` property value is updated to `UTF-8` if the previous value isn't a supported charset. That is done just before the `StaticProperty` class is referenced and loaded. Effectively, as noted in this comment, the `sun.jnu.encoding` would just have the right usable/supported value stored in `StaticProperty.jnuEncoding()` by the time we reach here. So this change looks fine to me. ------------- PR: https://git.openjdk.org/jdk/pull/12171
