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

[Jaikiran Pai]

On Tue, 24 Jan 2023 21:57:25 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:
> 
>   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