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

[Alan Bateman]

On Mon, 15 Nov 2021 17:32:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review the subject fix. In light of JEP400, Java runtime can/should start in UTF-8 charset if the underlying native encoding is not supported.
>
> 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/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.

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

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