RFR v5 - 8027634: Support @argfiles for java command-line tool

[Henry Jen]

On Aug 17, 2015, at 7:10 AM, Henry Jen <henry.jen at oracle.com> wrote:
> 
>> 
>> On Aug 16, 2015, at 4:51 PM, Henry Jen <henry.jen at oracle.com> wrote:
>> 
>> Thanks for reviewing, comment inline below,
>> 
>>> On Aug 14, 2015, at 4:07 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
>>> 
>>> 
>>>> On Aug 14, 2015, at 1:10 PM, Henry Jen <henry.jen at oracle.com> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Another minor revision address comments, no real behavior changes except use JLI_StrCmp instead of JLI_StrCCmp in checkArg().
>>>> 
>>>> http://cr.openjdk.java.net/~henryjen/jdk9/8027634/v5/webrev/
>>> 
>>> main.c
>>> JLI_PreprocessingArg returns NULL if not @argfile
>>> 
>>> Would it be better to return JLI_List containing one element as argv[i]?  We want to avoid new/free JLI_List for every argument and maybe a preallocated reusable copy for single element list to use (non-growable)?
>> 
>> Only argument with @prefix will be expanded, for any other cases, the function return NULL. This avoid any copy when not necessary. Regular argument is left alone, so that caller will just use the original value.
> 
> I think I may be talking at a different thing, guess you meant the make JLI_List JLI_PreprocessArg(const char*) to void JLI_PreprocessArg(JLI_List, const char*) and pass in a list to hold all the arguments.
> 
> That is reasonable. Considered that but didn’t do it eventually because not much benefits and hide the “expansion” fact. Since now you mentioned this, it probably worth to do it that way.
> 

Now I remember another reason I didn’t do it, because of the wildcard processing in cmdtoargs.c. I don’t want to convert every platform to use StdArg or maintain different version of PreprocesArgs.

I am going to leave it as it.

Cheers,
Henry