Codereview request for 4153167: separate between ANSI and OEM code pages on Windows
Ulf.Zibis at gmx.de
Mon Feb 13 15:15:22 PST 2012
thanks for your additional explanation.
One nit more...
Why you use the "sun." prefix? I think,
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:
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
> 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
>>>> 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? :
>> Shouldn't something be enough like
>> as counterpart to
More information about the core-libs-dev