On 07/20/2015 10:22 AM, Kirk Shoop wrote:
So when default system locale differs from the active one, we have different
behavior on Linux and Windows. The new options allow a windows user to select
the same behavior that one would expect on unix. The switches can certainly be
removed, if the compatibility impact is acceptable.
Kirk, on Windows file.encoding is from the user locale and the sun.jnu.encoding
is from
the system locale setting. sun.jnu.encoding is purely for those text encoding
sensitive
jnu functiond to communicate with the underlying windows system api, when the
system
locale and the user locale are set to different value. On unix/linux/osx, these
two are
always set to the same value. Yes, they might be input/output issue if the
encoding used
by the console (oem codepage) is not compatible with the encoding used by the "user
locale"
and you are trying to use System.in/out/err for the input/output to the console.
Here is the original CCC request regarding the sun.jnu.encoding, which might
provide
some background info.
http://cr.openjdk.java.net/~sherman/4958170.html
If you/we are NOT going to change the encoding used by the underlying console,
I don't
think we need/should change the "encoding" used by the java.io.Console. As I
suggested
in my previously email, the Java_java_io_Console_encoding() implementation
probably
need to update to return utf8 if the cp == 65001 (that was 10 years ago, I'm
not sure if
the 65001 was really used back then when we wrote this code). My understanding
of
the issue here is that if you continue to use the "A" version of the API to
parse/get the
arguments, and try to solve the possible issue triggered by the
"incompatibility" of the
oem encoding used by the console and the user locale encoding used by the
System.in/
out/err, it's fine to define a new system property to specify a preferred
encoding for the
launcher to use, but this "preferred" encoding should not be used by
java.io.Console.
But isn't it more reasonable to simply always use the "W" version for this
purpose in
launcher?
-Sherman
(2)
The defaultUnicodeCharset() method because it is called from java.io.Console()
constructor as well as from LauncherHelper. So its scope should be wider than
just LauncherHelper.java.
Kirk and Valery
-----Original Message-----
From: Xueming Shen [mailto:xueming.s...@oracle.com]
Sent: Saturday, July 11, 2015 11:51 AM
Hi Kirk,
Two questions
(1) Why do you need to change the "encoding" used by the java.io.Console class.
My understanding
is that the console encoding is specifically used to "talk" to the
underlying terminal, it should just
be the one used by the underlying terminal/console. I don't think the
proposed change updates
the underlying console encoding (something like chcp) when
-Dwindows.UnicodeConsole=true
specified, if I read the webrev correctly. Instead, the
Java_java_io_Console_encoding() probably
need to be updated to return utf8 if the cp == 65001, so if the
underlying terminal/console is
using cp65001, the java.io.Console should encode/decode in utf8.
I would assume the encoding of java.io.Condole should have nothing to do
with using
GetCommandLIneW() to parse the arguments in unicode in launcher?
(2) Why do you need a defaultUnicodeCharset() in Charset class? Seems to me the
scope should/could
be limited inside LauncherHelper.java?
Thanks,
-Sherman
