[rfc][icedtea-web] Option Parser

[Lukasz Dracz]

Hello,

I have taken in as much of your suggestions as I could. I have attached the updated Option Parser. I rewrote how the parser works and changed it from parsing inside a method to parsing in the constructor, as you should only really need to parse once. It stores the options in a Map with Options as Keys and a List of Strings for the values. The getValue(s) methods return based on the option from that map. 


>> +    public String[] getOptionValues(Option option) {
>> +        List<String> result = new ArrayList<String>();
>>
>> +        return result.toArray(new String[result.size()]);
>> +    }
>>
>Why not just return a `List<String>` instead?

In Boot it gets used by being put in a Map<String, String[]> which is then passed into the Launcher class.
I didn't want to change that up in this patch too. If you want I can add another method that could be used in the future called getListOfValues. 

>> +    public String[] getArgs() {
>> +        return Arrays.copyOf(args, args.length);
>> +    }
>
>Eh? Why expose internal state? Think about what needs to use this, and
>if an alternate implementation that does not expose the internals would
>be possible and/or better.

I looked into what was using this and it was ParserSettings so I redid the method to accept two booleans instead of
args which it would then look for the "-strict" and "-xml" tags inside of. This also meant changing the ParserSettingsTest which in my opinion don't make sense in their current state. I plan on looking into Parser and ParserSetting in the future and see how they are used and if it makes sense for them to be changed to incorporate the OptionParser.

The OptionsDefinitions Class is a shared class Jiri made that I have helped a bit on, I will update my optionsDefinitions Class with any further changes if required by Jiri. Also will update with the version Jiri sends out to the list.

For the parser I tried my best to make it as flexible as possible to cover as many possible various cases of how users might input their commands.

For example, the user can use the same tag multiple times and it won't matter

command -headless -headless -headless File.jnlp -headless -headless -headless

is the same as

command -headless File.jnlp 

also for ones that take multiple inputs you can have the tag multiple times

command -arg blue green red -headless File.jnlp -arg yellow purple

will have blue, green, red, yellow, purple all under arg
Notice however that -headless need to be before File.jnlp since the parser wouldn't know whether File.jnlp was just another arg or the main argument but after -headless which it knows takes no arguments it can be sure that File.jnlp is the main arg.

Currently writing a few more unit tests and testing out other cases but wanted to get feedback before I spent too much time on more unit tests.

Thank you,
Lukasz Dracz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: optionParser-10.patch
Type: text/x-patch
Size: 38729 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140904/07863e18/optionParser-10-0001.patch>