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

Ichiroh Takiguchi itakiguchi at openjdk.java.net
Thu Sep 30 10:13:32 UTC 2021


On Thu, 30 Sep 2021 09:36:34 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
> These commands use PrintWriter instead of standard out/err with PrintStream.

Screenshot
![javac-screenshot](https://user-images.githubusercontent.com/33543753/135429041-0ed22b36-0b1e-4626-92ca-8b58acf8872d.png)

javac does not use PrintStream for standard out/err, it uses PrintWriter.
I put some codes on src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java
* Using native.encoding system property. But test/langtools/tools/javac/diags/CheckResourceKeys.java was failed.
* 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.

jshell does not work as expected on b12

>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.

I don't think it's good fix, so please give me some advices.

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

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


More information about the core-libs-dev mailing list