On Sat, 6 Nov 2021 17:25:39 GMT, Alan Bateman <al...@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
