On Wed, 8 Sep 2021 22:15:12 GMT, Naoto Sato <na...@openjdk.org> wrote:
> The gist of the issue is that the test case now always creates the boot > classpath with non-ASCII chars appended, because the default encoding is > fixed to UTF-8 with the fix to JDK-8260265. > > On macOS, javaagent tries to load the class with US-ASCII determined by > nl_langinfo() (in unix/.../EncodingSupport_md.c). The file system encoding is > always UTF-8 on mac, so no need to use the determined encoding by > nl_langinfo(). > > On Linux, the "defaultEncoding" in Setup.java used to be US-ASCII in "C" > locale (which matches the result from nl_langinfo()), so no non-ASCII suffix > was appended to the `boot` path. But now the "defaultEncoding" is always > UTF-8, the setup code appends the non-ASCII suffix, which fails to read in > the native code using iconv with US-ASCII. The setup code should use the > encoding from "sun.jnu.encoding" instead. Actually, the code there was copied > from UnicodeTest.java which was modified with JDK-8260265, so the same fix > needs to be applied. > > Tier5 run succeeds with one unrelated failure. Also, fixed some typos, e.g. > "Uft8" -> "Utf8" Hi Naoto, > The file system encoding is always UTF-8 on mac, so no need to use the > determined encoding by nl_langinfo(). Doesn't it depend on the OS version and which file system is being used? HFS+ seems to use UTF-16 Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/5427
