Hi Rob,
Looks good, except a small nit, I would've written this with a positive
check
+ /* Copy the non-vm args */
+ for (i = 0; i < nargc ; i++) {
+ const char *arg = stdargs[i].arg;
+ if (arg[0] != '-' || arg[1] != 'J') {
+ argv = (StdArg*) JLI_MemRealloc(argv, (nargs+1) * sizeof(StdArg));
+ argv[nargs].arg = JLI_StringDup(arg);
+ argv[nargs].has_wildcard = stdargs[i].has_wildcard;
+ nargs++;
+ }
+ }
as follows.....
/* Copy the non-vm args */
for (i = 0; i < nargc ; i++) {
const char *arg = stdargs[i].arg;
if (arg[0] == '-' && arg[1] == 'J') // OR if (JLI_StrNCmp(arg, "-J",
JLI_StrLen("-J") == 0)
continue;
argv = (StdArg*) JLI_MemRealloc(argv, (nargs+1) * sizeof(StdArg));
argv[nargs].arg = JLI_StringDup(arg);
argv[nargs].has_wildcard = stdargs[i].has_wildcard;
nargs++;
}
Thanks
Kumar
On 5/19/2015 6:58 AM, Rob McKenna wrote:
Hi folks,
Because of platform specifics the Java launcher contains some extra
wildcard expansion processing on Windows.
As part of this processing the list of args received by
CreateApplicationArgs (java_md.c) is compared to the original list in
the java launchers main method.
Unfortunately the CreateApplicationArgs list has already been filtered
by TranslateApplicationArgs which removes VM specific flags. This
results in the launcher incorrectly neglecting to expand wildcard
arguments.
This fix filters the main method args in the same way so
CreateApplicationArgs will be comparing like with like.
http://cr.openjdk.java.net/~robm/8077822/webrev.01/
-Rob