RFR: 8274544: Langtools command's usage were grabled on Japanese Windows

Naoto Sato naoto at openjdk.java.net
Thu Sep 30 21:48:27 UTC 2021


On Thu, 30 Sep 2021 10:10:31 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> * Using native.encoding system property. But test/langtools/tools/javac/diags/CheckResourceKeys.java was failed.

What was the cause of the failure?

> * Use java.io.Console, like Console cons = System.console() and cons.charset(), but "javac 2>&1 | more" does not work as expected because System.console() returns null.
> 
> So I added -Dfile.encoding=COMPAT expect java and javaw commands on launcher.

I think we should fix the root cause of this, instead of specifying `file.encoding=COMPAT`

> 
> jshell does not work as expected on b12

Do you mean `b13`?

> 
> ```
> >jdk-18-b12\bin\jshell.exe
> |  JShellへようこそ -- バージョン18-ea
> |  概要については、次を入力してください: /help intro
> 
> jshell> "\u3042".getBytes()
> $1 ==> byte[2] { -126, -96 }
> ```
> 
> on b13
> 
> ```
> >jdk-18-b13\bin\jshell.exe
> |  JShellへようこそ -- バージョン18-ea
> |  概要については、次を入力してください: /help intro
> 
> jshell> "\u3042".getBytes()
> $1 ==> byte[3] { -29, -127, -126 }
> ```
> 
> It's UTF-8, not native encoding. I think backend java process should use same fine.encoding system property setting.

No it should not. `file.encoding` should not be inherited.

Naoto

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

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


More information about the core-libs-dev mailing list