On Mon, 29 Nov 2021 17:29:03 GMT, Naoto Sato <na...@openjdk.org> wrote:
>> As I explained before, output file encoding which is created by `-Xstdout` >> option is changed to native encoding instead of UTF-8 by >> `-J-Dfile.encoding=COMPAT`. >> In case of Linux ja_JP.eucjp locale, your explanation may be acceptable. >> But how about Windows platform ? >> How can user find encoding name without running java ? > >> But how about Windows platform ? > > If the user specifies `-J-Dfile.encoding=COMPAT`, all operations are done in > `MS932` on Japanese Windows. > >> How can user find encoding name without running java ? > > I still don't get why the user needs to know the encoding if they specifies > `COMPAT` property. Hello @naotoj . I discussed this issue with my colleagues. With `-J-Dfile.encoding=COMPAT` option, the working behavior is the same as JDK17, so there is no disadvantage. However, `-Xstdout` output file cannot be UTF8 encoded and we will not benefit from JEP-400 enhancements. I expected that garbled character related issues could be solved easily by JEP-400 if javac command output is encoded by UTF8. By using `-encoding` option with encoding name, javac command output can be UTF8 encoded. But it's not easy to pick up right locale/platform encoding name except for well known users. Anyway, when I find actual issue with `-J-Dfile.encoding=COMPAT` option for javac command, I will open new one. ------------- PR: https://git.openjdk.java.net/jdk/pull/6475
