Support Map options with key-only (support -Dkey as well as -Dkey=value)

[remkop]

From the picocli google group by @maxandersen:

I might already asked this but couldn't find the answer...

is there a way to have something like:

@CommandLine.Option(names = { "--D" })
Map<String, Optional> properties;

similar to how key/value properties works in maven that -Dxyx means xyz is set.

in other words - anyway to mark that the [=value] part is optional ?

---

(my reply on the mailing list)

Currently (as of picocli 4.5.1), unfortunately not:
picocli will throw an exception (Value for option -D should be in KEY=VALUE format but was xyz)
if the value for the -D option does not contain a '=' character.

Would you mind raising a ticket on the picocli GitHub issue tracker for this? (It is easier for me to track TODO items on GitHub than on Google groups...)

There are several ways this could be improved:

• make the value optional if the Map is defined with Optional for the value type: Map<KeyType, Optional>
• have a parser option like CommandLine.setMapOptionsRequireValue (default true for backwards compatibility)
• have an annotation attribute like fallbackValue (perhaps a different one, unsure if it is a good idea to use the existing fallbackValue attribute for this)
• it would also be nice to have some way for applications to customize the Key-Value separator (currently it is hard-coded to '=')

[dwalluck]

@remkop Someone had just asked about one of our tools supporting -Dkey as being equivalent to -Dkey=true similar to what mvn allows.

At first I hoped that it could be done via the customer parameter processing feature. If I could simply preprocess the command line to change -Dkey to -Dkey=true as if that was literally what the user had typed on the command line, then no changes to the Map processing would be necessary.

Also, a lot of the handling for the Map type is complex and all the methods are private anyway so it really doesn't seem possible to override this behavior.

[remkop]

I’m working on this now.
This will be in the next release.

[dwalluck]

As a general question, I was just wondering if preprocessing the tokens on the command line to agree with the expected input of the parser might help as a general solution rather than having to add custom code the parser every time. 😃

[remkop]

I can see why a custom IParameterConsumer is not easy to create for this case. The map processing is quite complex.

It may be interesting to introduce a new IParameterPreProcessor API, where the difference with IParameterConsumer is that after the preprocessor is invoked, picocli may still process the value (perhaps depending on the return value of the preprocessor). This may also be a good solution for #1217. Thanks for raising this idea!

[remkop]

My current thoughts on the behaviour for when -Dkey is specified without value:

• if the Map is defined as Map<K, Optional<V>>, picocli will add an entry for the specified key, with value Optional.empty()
• Otherwise, the default value becomes "" (an empty String). This is similar to the behaviour of system properties when -Dkey is specified without value on the command line.
• For some value types, converting the empty String to that type will cause an exception. This is not a real change: it is similar to end users previously specifying -Xkey=; with this change, the = simply becomes optional when there is no value.
• Previously, picocli would throw an exception ("Value for option -D should be in KEY=VALUE format but was xyz"). Applications relying on this exception will need to make changes and add validation to their business logic.

It would be nice to also support other key-value separators for Map options.
I am thinking this should be a new attribute in @Option and @Parameters, perhaps mapKeyValueSeparator.
I will create a separate ticket for that.

[remkop]

I may split off the support for Map<K, Optional<V>> to another ticket (I will add a comment to #1108),
and go ahead with implementing this so that the value becomes "" (empty space) when -Dkey is specified.

Support for Optional is more involved because it may requires changes to type converters and to how types are represented internally.

[remkop]

After looking at this some more, it may be more generic to let the value become null instead of "" (empty String) when -Dkey is specified. This would allow Map options with other generic types than String to work without error, for example:

@Option(names = "-x") Map<String, Integer> map;

One potential drawback is that applications that relied on the picocli validation may not be ready to deal with null map values and get NullPointerException at runtime.