RFR: 8275007: Java fails to start with null charset if LC_ALL is set to certain locales

[Naoto Sato]

On Sat, 6 Nov 2021 17:25:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Thanks @AlanBateman .
>> In my understanding, sun.jnu.encoding property may be related file system access.
>> Java may not be access to appropriate file.
>> I mean if the file name has malformed character, it may be changed to "?".
>> In this case, unexpected file access may be happened.
>> 8-bit pass-through may be better...
>
>> In my understanding, sun.jnu.encoding property may be related file system access.
>> Java may not be access to appropriate file.
> 
> Yes, it's a JDK internal property with the charset name to use when decoding or encoding file names (not the file content). The issue in this PR is about what to do when starting in unsupported configurations. In the recent releases the JDK will typically NPE or fail with an exception. Since JEP 400 this no longer impacts the default charset because it is UTF-8. This moves the problem on to choosing a fallback for places in the JDK that use the value of native.encoding or sun.jnu.encoding. I think the only choices to either fail at startup or default to UTF-8 as proposed.

Thanks, @AlanBateman for the explanation.
@takiguc, this is not part of JEP400, but really is a bug fix where the launcher fails to start with an NPE (on recent releases), which incorrectly called `new String(byte[])` assuming it would default to iso-8859-1, by calling `Charset.defaultCharset()`. NPE is thrown because at that `initPhase1`, system property is yet to be initialized. The gist of the change is to replace it with `new String(byte[], UTF_8) so that it does not call `Charset.defaultCharset()`.

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

PR: https://git.openjdk.java.net/jdk/pull/6282