Codereview request for 4153167: separate between ANSI and OEM code pages on Windows (original) (raw)

Ulf Zibis Ulf.Zibis at gmx.de
Mon Feb 13 23:15:22 UTC 2012

Sherman,

thanks for your additional explanation.

One nit more... Why you use the "sun." prefix? I think, "stdout.encoding" "stderr.encoding" would be enough + nicer. In some years, nobody will have any association with 'sun'. On the other hand, it would be more true to use: "windows.stdout.encoding" "windows.stderr.encoding"

-Ulf

Am 14.02.2012 00:02, schrieb Xueming Shen:

To have separate sun.stdout.encoding and sun.stderr.encoding is mainly because of implementation convenience. I need three things from the native (1) is std.out tty (2) is std.err tty (3) the console encoding if (1) or (2) are true, and I tried to avoid to go down to native multiple times it appears passing back two encoding name is the easiest approach. The original plan was to remove them after use, maybe via sun.misc.VM.saveAndRemoveProperties() (or simply remove them directly), but then thought the info might be useful... Auto detect the encoding of InputStreamReader when it is attached the console is nice to have, but I would try to avoid doing that until I have to, before that I would still advise the use of java.io.Console class:-) -Sherman

Why are there theoretically different code pages for stdout and stderr? you can re-direct std err to a log file file but keep the std out to the console, or re-direct the std out but keep the std.err to the console, in these scenario, the stderr and stdout will use different code page. Basically the approach is that if the otuput stream gets re-directed, it keeps using the default charset (with the assumption that the rest of the world is using the Windows codepage), if not, use the oem codepage from the console on Windows, to make sure the System.out/err outputs the bits that the underlying console can understand. Oops, I'm not sure, if you didn't misunderstood me. I mean, why are there 2 different properties? : "sun.stdout.encoding" "sun.stderr.encoding" Shouldn't something be enough like "console.encoding" as counterpart to "file.encoding" ? -Ulf

More information about the core-libs-dev mailing list