<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