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
