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

[Naoto Sato]

On Wed, 17 Nov 2021 13:02:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace jnuEncoding in jni_util.c with UTF-8, if platform encoding is not supported
>
> src/java.base/share/classes/sun/nio/fs/Util.java line 43:
> 
>> 41:         Charset.forName(
>> 42:             GetPropertyAction.privilegedGetProperty("sun.jnu.encoding"),
>> 43:             sun.nio.cs.UTF_8.INSTANCE);
> 
> Startup will ensure that sun.jnu.encoding has a value that is a supported encoding so I assume the the fallback in sun.nio.ch.Util is no longer needed.

Reverted the fix.

> src/java.base/share/native/libjava/jni_util.c line 825:
> 
>> 823:             }
>> 824:             (*env)->GetByteArrayRegion(env, hab, 0, len, (jbyte *)result);
>> 825:             result[len] = 0; /* NULL-terminate */
> 
> The change to newSizedStringJava is okay but I think the change to getStringBytes needs more eyes. Will it fall through to the code path sets it to FAST_UTF_8 during startup or does that happen later? If later then I assume there is a race with other threads that read jnuEncoding and potential for the JNI global ref to be freed from under their feet.

Good point. Removed the premature `jnuEncoding` initialization in `InitializeEncoding()`.

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

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