8274544: Langtools command's usage were garbled on Japanese Windows #5771

takiguc · 2021-09-30T09:36:34Z

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.

Progress

Change must not contain extraneous whitespace
Commit message must refer to an issue
Change must be properly reviewed

Issue

JDK-8274544: Langtools command's usage were garbled on Japanese Windows

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/5771/head:pull/5771
$ git checkout pull/5771

Update a local copy of the PR:
$ git checkout pull/5771
$ git pull https://git.openjdk.java.net/jdk pull/5771/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 5771

View PR using the GUI difftool:
$ git pr show -t 5771

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/5771.diff

bridgekeeper · 2021-09-30T09:38:04Z

👋 Welcome back itakiguchi! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2021-09-30T09:41:05Z

@takiguc The following labels will be automatically applied to this pull request:

core-libs
kulla

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

mlbridge · 2021-09-30T09:46:45Z

Webrevs

takiguc · 2021-09-30T10:10:31Z

Screenshot

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.

takiguc · 2021-09-30T11:18:16Z

/label i18n

openjdk · 2021-09-30T11:18:47Z

@takiguc
The i18n label was successfully added.

naotoj · 2021-09-30T21:45:15Z

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

takiguc · 2021-10-01T02:04:03Z

@naotoj
I applied following change on src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java

--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java
@@ -26,6 +26,7 @@
 package com.sun.tools.javac.util;

 import java.io.*;
+import java.nio.charset.Charset;
 import java.util.Arrays;
 import java.util.EnumMap;
 import java.util.EnumSet;
@@ -261,12 +262,22 @@ public class Log extends AbstractLog {
      * @param context the context in which to find writers to use
      * @return a map of writers
      */
+    private final static Charset nativeCharset;
+    static {
+        Charset cs = Charset.defaultCharset();
+        try {
+            cs = Charset.forName(System.getProperty("native.encoding"));
+        } catch (Exception e) {
+        }
+        nativeCharset = cs;
+    }
+
     private static Map<WriterKind, PrintWriter> initWriters(Context context) {
         PrintWriter out = context.get(outKey);
         PrintWriter err = context.get(errKey);
         if (out == null && err == null) {
-            out = new PrintWriter(System.out, true);
-            err = new PrintWriter(System.err, true);
+            out = new PrintWriter(System.out, true, nativeCharset);
+            err = new PrintWriter(System.err, true, nativeCharset);
             return initWriters(out, err);
         } else if (out == null || err == null) {
             PrintWriter pw = (out != null) ? out : err;

I got following exception via tools/javac/diags/CheckResourceKeys.java

Error: no match for "native.encoding"
java.lang.Exception: 1 errors occurred
        at CheckResourceKeys.main(CheckResourceKeys.java:59)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:568)
        at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
        at java.base/java.lang.Thread.run(Thread.java:833)

About jshell, my sample was not good,
See this one.
By b12

>jdk-18-b12\bin\jshell
|  JShellへようこそ -- バージョン18-ea
|  概要については、次を入力してください: /help intro

jshell> System.out.println("\u3042")
あ

By b13

>jdk-18-b13\bin\jshell
|  JShellへようこそ -- バージョン18-ea
|  概要については、次を入力してください: /help intro

jshell> System.out.println("\u3042")
縺・

By b13 with file.encoding=COMPAT

>jdk-18-b13\bin\jshell -J-Dfile.encoding=COMPAT
|  JShellへようこそ -- バージョン18-ea
|  概要については、次を入力してください: /help intro

jshell> System.out.println("\u3042")
縺・

If I need to create another issue, please let me know.

lahodaj · 2021-10-01T11:56:03Z

Regarding javac, the patch to Log.java seems to be in a reasonable direction: the write is to the physical System.out/err which should be done(?) using the native encoding. The order of the changed lines should be fixed, so that the javadoc is kept above the initWriters method. (As a secondary comment, it maybe a matter of discussion on whether keeping the native encoding in a static field is warranted here, but I don't mind it much.)

Regarding JShell, I guess I need to try to find a way to reproduce for me, so that I can debug. AFAIK the main process does not read/write from/to the console using System.in/System.out, so encoding plays no real role for the console, but it plays role in the communication between the agent and the main process.

pavelrappo · 2021-10-01T12:13:03Z

For searchability, you could fix the typo in the PR title and JBS summary: grABled -> gARbled. A nit, really.

lahodaj · 2021-10-01T12:21:24Z

Regarding javac, the patch to Log.java seems to be in a reasonable direction: the write is to the physical System.out/err which should be done(?) using the native encoding. The order of the changed lines should be fixed, so that the javadoc is kept above the initWriters method. (As a secondary comment, it maybe a matter of discussion on whether keeping the native encoding in a static field is warranted here, but I don't mind it much.)

I've forgot to write a note on the test, sorry: simply add native.encoding into noResourceRequired set in the test. The test checks that there are not hardcoded string that should be part of the resource bundle (and the resource bundle does not have unused keys), but names of system properties should be excluded, which is what the noResourceRequired set does.

takiguc · 2021-10-01T12:30:40Z

@pavelrappo Many thanks.
I changed PR and JBS.

naotoj · 2021-10-01T18:14:11Z

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.

takiguc · 2021-10-04T08:47:26Z

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 ?

lahodaj · 2021-10-04T10:24:01Z

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

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.

Thanks!

src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java

src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java

src/jdk.jpackage/share/classes/jdk/jpackage/main/Main.java

takiguc · 2021-10-05T16:00:56Z

Thanks, @lahodaj .
I opened JDK-8274784.

I tested your code, it worked fine on standard case !
Many thanks.

But, to execute previous saved command list, user needs to specify -J-Dfile.encoding=COMPAT and -R-Dfile.encoding=COMPAT options.
Do you have any idea about this kind of case ?

I'd like to discuss jshell things by JDK-8274784.

naotoj · 2021-10-06T00:02:55Z

I just grepped System.out/err in jshell source directory, and found another location in tool/JShellToolProvider.java that uses bare stdout/err. Would you also apply the fix and see the result?

AlanBateman · 2021-10-06T06:15:47Z

The changes in 4427d87 look okay. I assume most of these tools will never run with a SM enabled and don't need to be granted permission to reading native.encoding.

takiguc · 2021-10-06T15:55:34Z

Hello @naotoj .
Sorry I'm late.

I just grepped System.out/err in jshell source directory, and found another location in tool/JShellToolProvider.java that uses bare stdout/err. Would you also apply the fix and see the result?

I applied following changes and lahodaj's code (I'm not sure, it's expected one...)

                         : in;
         PrintStream xout =
                 (out == null)
-                        ? System.out
+                        ? new PrintStream(System.out, true, nativeCharset)
                         : (out instanceof PrintStream)
                                 ? (PrintStream) out
-                                : new PrintStream(out);
+                                : new PrintStream(out, true, nativeCharset);
         PrintStream xerr =
                 (err == null)
-                        ? System.err
+                        ? new PrintStream(System.err, true, nativeCharset)
                         : (err instanceof PrintStream)
                                 ? (PrintStream) err
-                                : new PrintStream(err);
+                                : new PrintStream(err, true, nativeCharset);
         try {
             return JavaShellToolBuilder
                     .builder()

But it did not work for previously saved encoded command list.
(lahodaj's code worked fine for standard case.)

I think you may be confused because of my bad explanation.
User can create Jshell's command list by /save.
Native encoding was used before JDK18.
Now UTF-8 is used by JDK18.
To read saved command list (/open) which was encoded by native encoding, Charset.defaultCharset() should be same as native.encoding...
I think we need to provide workaround for it.

naotoj · 2021-10-06T18:08:04Z

I got your issue now. Since the current code issues FileReader() without specifying the explicit charset, this is the prime example that is affected by the JEP. The question is, in which encoding the jshell save file should be? I think it belongs to the spec of jshell, and it should be specified somewhere in the document.

BTW, the suggestion I made in JShellToolProvider still holds regardless of the save file issue.

takiguc · 2021-10-08T17:41:34Z

Hello @naotoj .
Do you think I need to fix jshell issue by this PR ?

naotoj · 2021-10-08T18:13:41Z

Hello @naotoj . Do you think I need to fix jshell issue by this PR ?

I'd appreciate it, as I don't have a Japanese Windows environment at hand.

naotoj · 2021-10-08T21:07:32Z

BTW, does the PoC in the jshell bug report really causing the issue?

System.out.println("\u3042")

This is ASCII, so save/restore does not seem to cause any issues across JDKs with and without JEP400. Did you mean Systemout.println("あ") instead?

openjdk · 2021-10-19T20:45:04Z

@jonathan-gibbons
The compiler label was successfully added.

The javadoc label was successfully added.

takiguc · 2021-10-21T16:20:49Z

@jonathan-gibbons I appreciate your comment.
I'd like to confirm something.

This is pretty ugly code to be replicating so many times.
What if the tools have been run in an environment where System.out and System.err have already been redirected in some manner, with System.setOut or System.setErr? You should not assume that System.out and System.err will always refer to the console.

I was confused since the fixed code did not call System.out/System.err directly.
I tried following code on Japanese Windows.

import java.io.*;
import java.nio.charset.*;

public class OutputCheck {
    public static void main(String[] args) throws Exception {
         String s = "\u3042";
         System.out.println("[1]:"+s);
         PrintStream ps = System.out;
         System.setOut(new PrintStream(System.out));
         System.out.println("[2]:"+s);
         ps.println("[3]:"+s);
         System.setOut(new PrintStream(System.out, true, Charset.forName(System.getProperty("native.encoding"))));
         System.out.println("[4]:"+s);
    }
}

Output is:

> jdk-18-b14\bin\java OutputCheck.java
[1]:あ
[2]:縺・
[3]:あ
[4]:あ

[2] refers default charset (UTF-8)
[3] is same as [1]
[4] specifies native.encoding system encoding

Could you explain more detail ?

takiguc · 2021-10-25T16:01:07Z

Terminal setting

$ locale
LANG=ja_JP.eucjp
LC_CTYPE="ja_JP.eucjp"
LC_NUMERIC="ja_JP.eucjp"
LC_TIME="ja_JP.eucjp"
LC_COLLATE="ja_JP.eucjp"
LC_MONETARY="ja_JP.eucjp"
LC_MESSAGES="ja_JP.eucjp"
LC_PAPER="ja_JP.eucjp"
LC_NAME="ja_JP.eucjp"
LC_ADDRESS="ja_JP.eucjp"
LC_TELEPHONE="ja_JP.eucjp"
LC_MEASUREMENT="ja_JP.eucjp"
LC_IDENTIFICATION="ja_JP.eucjp"
LC_ALL=

Java testcase by using Scanner.

$ cat scan.java 
import java.util.*;

public class scan {
  public static void main(String[] args) throws Exception {
    System.out.println("Please input some characters:");
    Scanner scanner = new Scanner(System.in);
    System.out.println(scanner.next());
  }
}
$ ~/jdk-18-b19/bin/java scan.java
Please input some characters:
あいうえお
??????????

When src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/AbstractTerminal.java is modified

$ jshell
|  JShellへようこそ -- バージョン18-internal
|  概要については、次を入力してください: /help intro

jshell> import java.nio.charset.*

jshell> System.out.println(System.getProperty("native.encoding"))
EUC-JP-LINUX

jshell> System.out.println(Charset.defaultCharset())
UTF-8

jshell> var scan = new Scanner(System.in)
scan ==> java.util.Scanner[delimiters=\p{javaWhitespace}+] ... \E][infinity string=\Q∞\E]

jshell> var s = scan.next()
あいうえお
s ==> "あいうえお"

jshell> System.out.println(s)
あいうえお

jshell> /exit
|  終了します
$

takiguc · 2021-11-02T00:16:08Z

I needed to rebase my fixed code since JavapTask.java and JdepsTask.java were updated.

Hello @jonathan-gibbons .
Could you check new fixes ?
I changed following parts:

Native charset is generated on com/sun/tools/javac/util/Log.java.
module-info.java was updated

Hello @naotoj .
Could you check new fixes again ?

naotoj · 2021-11-03T18:41:19Z

Firstly, please do NOT rebase your fix, as it will clobber the review history. Use merge instead.
As to the fix, I am not sure consolidating the code into Log.java would be OK as it would introduce module dependency.

takiguc · 2021-11-04T16:55:00Z

@naotoj
I'm sorry about my bad operation.

@jonathan-gibbons
I appreciate if you give me some suggestions.

takiguc · 2021-11-08T17:09:37Z

Hello @jonathan-gibbons .
I tested -Xstdout option for javac command on Linux and Windows platform.
Output file encoding was UTF-8.
I assume it's expected result.

jonathan-gibbons

I strongly dislike this proposed changeset. In my opinion, the original change that has provoked the changes here is a bad/incompatible change, and should maybe be reconsidered. The fact that a change in the Java runtime has triggered the need for so many changes in application-style code is some sort of giant "canary in the coalmine".

Generally, the issue is related to the fact that we wrap a PrintStream in a PrintWriter ... and, if I understand correctly, the writer ends up with the wrong character encoding. Is it possible to change PrintWriter and/or PrintStream so that the correct underlying encoding used by the PrintStream is also used by the PrintWriter. That way, all existing uses where a PrintWriter wraps a PrintStream would continue to work without any modification.

cc: @jddarcy with his CSR hat on, for the compatibility issues relating to the issue that caused the problems being addressed here.

jonathan-gibbons · 2021-11-10T19:41:29Z

Informally, I suggest one of the following:

PrintStream(OutputStream) and PrintStream(OutputStream, boolean) should be redefined so that they internally check if the stream arg is a PrintStream, in which case they use the encoding from the PrinStream instead of the default.
or, add new overloads for PrintStream(PrintStream) and PrintStream(PrintStream, boolean) that are defined to use the character encoding from the PrintStream arg.

I note that PrintStream does not expose a "getter" for the encoding. That seems like a bug in itself, but even without fixing that, PrintWriter ought to be able to access the encoding "behind the scenes".

AlanBateman · 2021-11-10T19:46:09Z

Generally, the issue is related to the fact that we wrap a PrintStream in a PrintWriter ... and, if I understand correctly, the writer ends up with the wrong character encoding. Is it possible to change PrintWriter and/or PrintStream so that the correct underlying encoding used by the PrintStream is also used by the PrintWriter. That way, all existing uses where a PrintWriter wraps a PrintStream would continue to work without any modification.

JEP 400 has moved the JDK to using UTF-8 as the default charset, a long overdue change. So if you create a PrintStream or a PrintWriter without specifying the charset then it will default to UTF-8. The issue that I think we have with javac and a few other tools is that they are creating PrintWriters on PrintStreams where the underlying streams are stdout/stderr and so using the native encoding. There was exploration into special casing this scenario during JEP 400 that was rejected because it complicates the spec and may not be feasible in cases where there are many layers in the onion. If there is resistance to fixing the tools then we might have to re-visit this. Naoto may have more to say on this.

AlanBateman · 2021-11-10T20:00:39Z

PrintStream(OutputStream) and PrintStream(OutputStream, boolean) should be redefined so that they internally check if the stream arg is a PrintStream, in which case they use the encoding from the PrinStream instead of the default.

I think you mean the PrintWriter constructors here. Yes, there is merit in that. PrintStream is a bit unusual in that it's an OutputStream but it has a charset because it prints text output.

naotoj · 2021-11-10T21:19:30Z

Good suggestions. Filed a JBS issue: https://bugs.openjdk.java.net/browse/JDK-8276970

jonathan-gibbons · 2021-11-10T21:44:58Z

PrintStream(OutputStream) and PrintStream(OutputStream, boolean) should be redefined so that they internally check if the stream arg is a PrintStream, in which case they use the encoding from the PrinStream instead of the default.

I think you mean the PrintWriter constructors here. Yes, there is merit in that. PrintStream is a bit unusual in that it's an OutputStream but it has a charset because it prints text output.

Yes, sorry for the confusion.

jonathan-gibbons · 2021-11-10T21:52:29Z

If there is resistance to fixing the tools then we might have to re-visit this.

It's not just the JDK tools that are an issue. I think that wrapping some PrintStream into a PrintWriter is a common enough idiom that it is not reasonable to fix all occurrences -- i.e. including those outside of JDK.

takiguc · 2021-11-14T16:45:07Z

Hello @naotoj .
For PrintStream.getCharset(), following changes may be required.

+++ src/java.base/share/classes/java/io/OutputStreamWriter.java
+    Charset getCharset() {
+        return se.getCharset();
+    }

+++ src/java.base/share/classes/java/io/PrintStream.java
+    public Charset getCharset() {
+        return charOut.getCharset();
+    }

+++ src/java.base/share/classes/sun/nio/cs/StreamEncoder.java
+    public Charset getCharset() {
+        return cs;
+    }

For javac code, we may not use PrintStream.getCharset() directly because javac code is compiled by boot compiler.
We need to use reflection, like:

+++ src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java
+    private static Charset getCharset(PrintStream ps) {
+        try {
+            Method getCharset = PrintStream.class.getDeclaredMethod("getCharset");
+            return (Charset)getCharset.invoke(ps);
+        } catch (Exception e) {
+            return Charset.defaultCharset();
+        }
+    }

If we add following constructors against PrintWriter, we just change javap and jshell code.
But I cannot evaluate this code changes.

+++ src/java.base/share/classes/java/io/PrintWriter.java
+    public PrintWriter(PrintStream ps) {
+       this((OutputStream)ps, false, ps.getCharset());
+    }
+    public PrintWriter(PrintStream ps, boolean autoFlush) {
+       this((OutputStream)ps, autoFlush, ps.getCharset());
+    }

I really appreciate if you handle this kind of code change via JEP-400.

jonathan-gibbons · 2021-11-15T19:57:12Z

Generally, I think it would be a good goal for JEP-400 to not require any source-code changes to any use-sites, at least for this common idiom of wrapping a PrintStream in a PrintWriter. While we may have the ability to change JDK use-sites, we do not have the ability to change any usages outside of JDK, and we should try not to break those usages in the way that the JDK tools have been broken.

naotoj · 2021-11-15T21:15:50Z

The gist of the issue is that PrintWriter (w/o explicit charset) uses the default charset, ignoring PrintStream's charset. So it basically is irrelevant of JEP400, but apparently, JEP400 made it visible as it keeps the System.out/err encoding in native.encoding while changing the default to UTF-8.
I am now in the process of creating a PR for the issue JDK-8276970, and will submit it shortly.

naotoj · 2021-11-19T16:48:03Z

I think this PR can now safely be withdrawn, as #6401 is now integrated. @takiguc, if you do not mind, I will create a PR for the remaining jshell issue. Please let me know.

takiguc · 2021-11-22T16:13:38Z

Thanks @naotoj .
I opened new pr via 8274784.
I'd like to close this pr since main issue was fixed by #6401.

takiguc changed the title ~~Langtools command's usage were grabled on Japanese Windows~~ 8274544: Langtools command's usage were grabled on Japanese Windows Sep 30, 2021

openjdk bot added the rfr Pull request is ready for review label Sep 30, 2021

openjdk bot added core-libs core-libs-dev@openjdk.org kulla kulla-dev@openjdk.org labels Sep 30, 2021

openjdk bot added the i18n i18n-dev@openjdk.org label Sep 30, 2021

takiguc changed the title ~~8274544: Langtools command's usage were grabled on Japanese Windows~~ 8274544: Langtools command's usage were garbled on Japanese Windows Oct 1, 2021

naotoj reviewed Oct 4, 2021

View reviewed changes

openjdk bot added the javadoc javadoc-dev@openjdk.org label Oct 19, 2021

takiguc force-pushed the 8274544 branch from 4427d87 to e2a8784 Compare October 25, 2021 14:16

takiguc added 5 commits November 1, 2021 15:44

Langtools command's usage were grabled on Japanese Windows

68d5b2e

8274544: Langtools command's usage were garbled on Japanese Windows

6c26d97

8274544: Langtools command's usage were garbled on Japanese Windows

28fbf73

8274544: Langtools command's usage were garbled on Japanese Windows

e307b62

8274544: Langtools command's usage were garbled on Japanese Windows

6e6adc3

takiguc force-pushed the 8274544 branch from e2a8784 to 6e6adc3 Compare November 1, 2021 16:05

jonathan-gibbons suggested changes Nov 10, 2021

View reviewed changes

naotoj mentioned this pull request Nov 15, 2021

8276970: Default charset for PrintWriter that wraps PrintStream #6401

Closed

3 tasks

takiguc mentioned this pull request Nov 22, 2021

8274784: jshell: Garbled character was displayed by System.out.println(...) on Japanese Windows #6505

Closed

3 tasks

takiguc closed this Nov 22, 2021

8274544: Langtools command's usage were garbled on Japanese Windows #5771

8274544: Langtools command's usage were garbled on Japanese Windows #5771

Conversation

takiguc commented Sep 30, 2021 • edited by openjdk bot Loading

Progress

Issue

Reviewing

bridgekeeper bot commented Sep 30, 2021

openjdk bot commented Sep 30, 2021

mlbridge bot commented Sep 30, 2021 • edited Loading

Webrevs

takiguc commented Sep 30, 2021

takiguc commented Sep 30, 2021

openjdk bot commented Sep 30, 2021

naotoj commented Sep 30, 2021

takiguc commented Oct 1, 2021

lahodaj commented Oct 1, 2021

pavelrappo commented Oct 1, 2021 • edited Loading

lahodaj commented Oct 1, 2021

takiguc commented Oct 1, 2021

naotoj commented Oct 1, 2021

takiguc commented Oct 4, 2021

lahodaj commented Oct 4, 2021

takiguc commented Oct 5, 2021

naotoj commented Oct 6, 2021

AlanBateman commented Oct 6, 2021

takiguc commented Oct 6, 2021

naotoj commented Oct 6, 2021

takiguc commented Oct 8, 2021

naotoj commented Oct 8, 2021

naotoj commented Oct 8, 2021 • edited Loading

openjdk bot commented Oct 19, 2021

takiguc commented Oct 21, 2021

takiguc commented Oct 25, 2021

takiguc commented Nov 2, 2021

naotoj commented Nov 3, 2021

takiguc commented Nov 4, 2021

takiguc commented Nov 8, 2021

jonathan-gibbons left a comment • edited Loading

Choose a reason for hiding this comment

jonathan-gibbons commented Nov 10, 2021

AlanBateman commented Nov 10, 2021

AlanBateman commented Nov 10, 2021

naotoj commented Nov 10, 2021

jonathan-gibbons commented Nov 10, 2021

jonathan-gibbons commented Nov 10, 2021

takiguc commented Nov 14, 2021

jonathan-gibbons commented Nov 15, 2021

naotoj commented Nov 15, 2021

naotoj commented Nov 19, 2021

takiguc commented Nov 22, 2021

takiguc commented Sep 30, 2021 •

edited by openjdk bot

Loading

mlbridge bot commented Sep 30, 2021 •

edited

Loading

pavelrappo commented Oct 1, 2021 •

edited

Loading

naotoj commented Oct 8, 2021 •

edited

Loading

jonathan-gibbons left a comment •

edited

Loading