0

Given the following environment:

  • Windows 10
  • Language is set to Japanese
  • Language for non-unicode programs is set to Japanese
  • Java program is run on console

Upon execution, an IOException is encountered, and the message expected in the console is as follows: 既存の接続はリモート ホストに強制的に切断されました。 (translates to "An existing connection was forcibly closed by the remote host") Please see code snippet below:

private void onIOException(IOException e, AbstractConnection connection)
{
    String reason = e.getMessage();
    ...
    log.error("Closing ",connection," because ",reason);
}

When running in Java 8, the message is printed correctly. However, when running in Java 9, the message is printed as 譌｢蟄倥?ｮ謗･邯壹?ｯ繝ｪ繝｢繝ｼ繝? 繝帙せ繝医↓蠑ｷ蛻ｶ逧?縺ｫ蛻?譁ｭ縺輔ｌ縺ｾ縺励◆縲?

After some investigation, it was found that in Java 9, the byte array used to represent the same string contains a different set of values ([-24, -83, -116, -17, -67, ...]). In Java 8, the string used to be represented in bytes as ([-26, -105, -94, -27, -83, ...]). In Java 9, if we construct the string using the byte array used in Java 8, the message is printed correctly. This seems to be caused by compact strings as well, since strings are no longer stored as char arrays.

We have tried the following:

  • using system property java.locale.providers
  • using system property file.encoding
  • using console command chcp with different values
  • disabling compact strings via "-XX:-CompactStrings"

We've also tried combinations but to no avail as well.

This is related to a previous question IOException message not printed correctly when using Java 9 on Windows 10 set to Japan locale and language as well (I am unable to add details via comment or answer).

Does anybody have an idea on this issue? Thanks!

javayoyo
  • 1
  • 1
  • Do you know which API is throwing the IOException? Also have you tried JDK 11 or 12 see if the issue has been fixed. – Alan Bateman Jul 02 '19 at 14:28
  • The bytes, you have posted, are UTF-8 representations of the strings which have nothing to do with the way, the strings are represented internally. But since looking at the UTF-8 representations of the strings revealed that they indeed have the contents shown in the console, you do already know, that the printing is not the problem. Which leads to the question, Alan Bateman already asked, where do these exceptions come from/ how are their messages constructed. – Holger Jul 02 '19 at 14:44
  • Thank you for your comments! I can confirm that this works, without any added arguments, on JDK 11 and 12 (still not fixed on JDK 10). – javayoyo Jul 03 '19 at 02:51

0 Answers0