<i18n dev> RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v5]
Alan Bateman
alanb at openjdk.java.net
Wed Nov 10 19:49:45 UTC 2021
On Wed, 10 Nov 2021 19:16:58 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:
> 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.
-------------
PR: https://git.openjdk.java.net/jdk/pull/5771
More information about the i18n-dev
mailing list