RFR 8124977 cmdline encoding challenges on Windows

[Kumar Srinivasan]

Hi Kirk,

I took another pass over the changes.

IMHO, we need to make it easier for people to use this feature,
and eliminate these two, atleast externally.

"-Dwindows.UnicodeConsole=true",
"-Dfile.encoding.unicode=\"UTF-8\"",

Can we invent a new command line arg ? we can make it an -X
flag, by inspecting the args, we can set the two properties,
preferably one ? and also make the decision to use Wide
character translations etc.

1. java_md.c

a.> + ConvertWinArgsToCommonFormat(cmdLineUtf8, pargc, pargv); + 
JLI_MemFree(cmdLineUtf8); The free may not happen under error 
conditions, though we return immediately memory checking tools are 
likely to complain about memory leak.
b.>

+        if (stricmp(arg, "-Dwindows.UnicodeConsole=true") == 0) {
For consistency sake there there is a wrapper for this.
69 #define JLI_StrCaseCmp(p1, p2)          stricmp((p1), (p2))


As for the test you can delete the shell test and all you need is the
following, I have not tested it, but it should work.
#####################
UnicodeCmdVerifier.java
#####################
<Copyright deleted for clarity>

/*
* @test
* @bug 8124977
* @summary ensures that the command line argument, passed as Unicode,
* matches the desired value.
* @compile -XDignore.symbol.file UnicodeCmdVerifier.java
* @run main UnicodeCmdVerifier
*/
public class UnicodeCmdVerifier extends TestHelper {
public static void main(String[] args) {
if (!isWindows) { // test is applicable only on Windows
return;
}
if (args != null && args.length > 0) {
String desired = new String("\u042e\u043d\u0438\u043a\u043e\u0434");
if (args[1].equals(desired)) {
System.out.println("The argument matches the desired text: " + args[0]);
return;
} else {
throw new Error("The argument does not match the desired text: "
+ args[0] + " != " + desired);
}
return;
}
TestResult tr = doExec(javaCmd,
"-cp", TEST_CLASSES_DIR.getAbsolutePath(),
"-Dwindows.UnicodeConsole=true",
"-Dfile.encoding.unicode=\"UTF-8\"",
"UnicodeCmdVerifier", "testme", "Юникод");
if (!tr.isOK()) {
throw new Error("test failed with a non-zero exit");
}
}
}


Thanks
Kumar

On 7/8/2015 9:50 AM, Kirk Shoop wrote:
>> -----Original Message-----
>> From: Kumar Srinivasan [mailto:kumar.x.srinivasan at oracle.com]
>>
>> Hi Kirk,
>>
>> Thanks for proposing this change.
>>
>> If you notice all the posix calls are wrapped in JLI_* this  gives us the
>> ability to use "W" functions.  I almost got it done, several years ago,
>> but we upgraded to VS2010 and my work based on VS2003 keeled over,
>> meanwhile my focus was  "shifted" to something else.
>>
>> main.c: is really envisioned to be a stub  compiled by the tool launchers,
>> like java, javac, javah, jar etc. I prefer to see all the heavy logic in
>> this file moved to the platform specific file windows/java_md.*
>>
> Heavy logic is moved out of main.c file.
>
>> For the reason specified above we need to move fprintf or any naked posix
>> calls to JLI_* indirections.
>>
> Posix calls are wrapped in JLI_* functions.
>
>> I don't see any tests ? The tests must be written in java and placed in
>> jdk/test/tools/launcher, there is a helper framework TestHelper.java.
>>
> A new test for our changes is added.
>
>> There are other changes in nio, charsets etc, this will be reviewed by my
>> colleague specializing in that area (Sherman) cc'ed.
>>
>>
>> Thanks
>>
>> Kumar
> Thank you for the feedback!
>
> Valery prepared a new webrev which I placed here:
>    http://cr.openjdk.java.net/~kshoop/8124977/webrev.01
>
> Thanks,
> Kirk