RFR 8124977 cmdline encoding challenges on Windows

[Kirk Shoop]

Hi,

The switches were introduced to prevent compatibility impact for existing usage on Windows. If the impact is acceptable then the next webrev will remove both of them and instead change the default behavior on windows to read the commandline in Unicode and to output UTF-8 to a console that has chcp 65001.

How should this JLI_MemFree() call be protected? It seems that the only possible way to leak memory here is abnormal program termination.
Do we have any ways to call JLI_MemFree in that case? There appears to be other places where JLI_MemFree is used in a similar way, a pointer to an example of correct usage would be helpful.

Yes, JLI_StrCaseCmp will be used instead.

Yes, the 'UnicodeCmdVerifier' approach had already been tried, but if the Java test class executes itself an exception occurs in TestHelper:
  java.lang.Error: property test.classes not defined ??
        at TestHelper.<clinit>(TestHelper.java:117)
  Exception in thread "main"

I tried your code as well and get the same exception. I did not find an existing test calling itself, however there are a lot of tests that call or compile+call other classes.
So it seems we need two files, the caller class and the calling one, and if so is it ok to leave the test as is: shell script + Java class? It appears easier to read and modify.

Kirk and Valery

> -----Original Message-----
> From: Kumar Srinivasan [mailto:kumar.x.srinivasan at oracle.com]
> Sent: Tuesday, July 14, 2015 6:33 AM
> To: Kirk Shoop
> Cc: core-libs-dev Libs; Valery Kopylov (Akvelon); Martin Sawicki;
> SHEN,XUEMING; Henry Jen
> Subject: Re: RFR 8124977 cmdline encoding challenges on Windows
> 
> 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
>