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 kulla-dev
mailing list