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"

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

Commit messages:
 - Merge branch 'master' into JDK-8273188
 - 8273188: java/lang/instrument/BootClassPath/BootClassPathTest.sh fails with 
"FATAL ERROR in native method: processing of -javaagent failed, 
processJavaStart failed"

Changes: https://git.openjdk.java.net/jdk/pull/5427/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5427&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273188
  Stats: 36 lines in 8 files changed: 5 ins; 16 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5427.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5427/head:pull/5427

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

Reply via email to