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