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

Ichiroh Takiguchi itakiguchi at openjdk.java.net
Mon Nov 8 13:00:35 UTC 2021


On Mon, 8 Nov 2021 09:44:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> If this issue is not a part of JEP-400, I think UTF_8 may not be only solution for sun/nio/fs/Util.java.
>> Please explain why UTF_8 is better than ISO_8859_1.
>
>> If this issue is not a part of JEP-400, I think UTF_8 may not be only solution for sun/nio/fs/Util.java.
>> Please explain why UTF_8 is better than ISO_8859_1.
> 
> Just to add to Naoto's comment. When the JDK starts in unusual/unsupported configurations then it needs a default for the stdout/stderr print streams, for encoding/decoding files paths in java.io, and for encoding/decoding files paths in the java.nio.file implementation. It's important that the latter two are the same, having one be UTF-8 and the other be 8859-1 won't work.
> 
> There may be an argument that the JDK should emit a warning at startup.

Thanks @AlanBateman .
Yeah, I got a message from my co-worker.
He said unmappable  conversion was still there even if ISO8859_1, and there was no big difference between ISO8859_1 and UTF_8.

I'm very sorry for your confusion...

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

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


More information about the core-libs-dev mailing list