Hi Kirk,
We don't allow any shell tests. There are existing shell based tests,
I have not had a chance to port all of them.
Your test must be rewritten to use the TestHelper framework, please see
the other tests in jdk/test/tools/launcher for patterns.
Kumar
-----Original Message-----
From: Xueming Shen [mailto:xueming.s...@oracle.com]
Sent: Monday, July 20, 2015 11:50 AM
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
Thank you for the valuable feedback. We have vastly simplified the original
patch.
The new webrev is here:
http://cr.openjdk.java.net/~kshoop/8124977/webrev.02/
This webrev uses GetCommandLineW on windows to retrieve the UCS16 commandline and also
supports the 65001(UTF-8) codepage (set by chcp 65001) so that when
-Dsun.jnu.encoding="UTF-8" is supplied the console output (stdout & stderr)
will be in UTF8.
There are no new commandline switches.
Please let us know if there is anything else that needs improvement.
Thanks!
Kirk and Valery
