<i18n dev> RFR: 8274544: Langtools command's usage were garbled on Japanese Windows

Jan Lahoda jlahoda at openjdk.java.net
Mon Oct 4 10:27:08 UTC 2021

On Mon, 4 Oct 2021 08:47:26 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> The encoding used in `Log.java` should first check whether it is run within console or not. If `System.console()` returns the console, its `.charset()` should be used instead of `native.encoding` value.
>> As to the jshell issue, it is a different issue than javac, so I would expect it to be handled with a different issue.
> Helllo @naotoj .
> I used `System.console()` and `Console.charset()`.
> The following executables had same issue, I fixed them.
>> jar.exe, javac.exe, javadoc.exe, javap.exe, jdeps.exe, jlink.exe, jmod.exe, jpackage.exe
> I could not find out the following executables had same issue or not
>> jabswitch.exe, jcmd.exe, jfr.exe, jhsdb.exe, jimage.exe, jinfo.exe, jmap.exe, jps.exe, jrunscript.exe, jstack.exe, jstat.exe, jstatd.exe, kinit.exe, klist.exe, ktab.exe
> The following executables worked fine.
>> jarsigner.exe, java.exe, javaw.exe, jdb.exe, jdeprscan.exe, jshell.exe, keytool.exe, rmiregistry.exe, serialver.exe
> The following executables were GUI apps
>> jaccessinspector.exe, jaccesswalker.exe, jconsole.exe
> These fixes don't have testcases.
> Do you have any idea about testcase for this issue ?

@takiguc - if JShell is still an issue, is there a chance you could try this:

Not sure if it will help, but it might (this won't change the default charset, but could send the output in a sensible encoding for the console.



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

More information about the i18n-dev mailing list