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
