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.shen@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