<i18n dev> RFR: 8277398: javac does not accept encoding name COMPAT [v2]
Ichiroh Takiguchi
itakiguchi at openjdk.java.net
Wed Dec 1 08:52:31 UTC 2021
On Mon, 29 Nov 2021 17:29:03 GMT, Naoto Sato <naoto at 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
More information about the i18n-dev
mailing list