Set optional parameters to empty container if type is array or collection
See original GitHub issueHi there,
I recently had the following situation:
@Parameters(arity = "0..*", description = "tbd") private Set<Type> someParams;
If I do not specify any params at command line, someParams
is null
which is a bit surprising / annoying when it comes to working with arrays / collections.
The Documentation says:
If the field is null, picocli will instantiate it.
Which does not seem to be the case if no params are specified.
Is this the default picocli behavior? Do I miss something?
I would like picocli to create an empty array / collection in this case. This helps to keep the code simple and comprehensible as checking for null
on container members is odd and causes boiler plate.
Thank you very much for any input on this.
Issue Analytics
- State:
- Created 6 years ago
- Comments:6 (4 by maintainers)
Top Results From Across the Web
c# - Passing an empty array as default value of an optional ...
The compiler will automatically pass an empty array if it is not specified, and you get the added flexibility to either pass an...
Read more >Optional (Java Platform SE 8 ) - Oracle Help Center
Returns an Optional describing the specified value, if non-null, otherwise returns an empty Optional . Type Parameters: T - the class of the...
Read more >26 Reasons Why Using Optional Correctly Is Not Optional
Favor returning an empty collection/array. With this in mind, rely on Collections.emptyList() , emptyMap() , and emptySet() . In order to keep ...
Read more >Immutable objects
Generally, builders compensate for the lack of named and optional constructor arguments in the Java language. To create a builder, invoke the static...
Read more >std::optional - cppreference.com
the type of the value to manage initialization state for. The type must meet the requirements of Destructible (in particular, array and reference...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
You are correct that this is the current behaviour: fields are only instantiated if picocli finds a matching argument on the command line.
For single-value fields, this allows applications to detect which options and parameters were specified on the command line, and which ones were not. For consistency I kept the same behaviour with multi-value fields (arrays and collections).
Overall, picocli can be improved in the area of assigning default values. I recently started thinking about this more after discussion in issue #261. It seems to me that your request falls into the category of “picocli needs better defaulting”, so is related to #261. I can easily imagine a
IDefaultValueProvider
implementation that instantiates multi-value fields…Question though, if the main concern is avoiding null-checking, why not simply instantiate the field with the declaration, like this:
Yes, that is correct. Field initializers are currently the only way to provide default values. (For arrays and collections, there is one “gotcha”: if you specify a non-null array or collection, picocli will add values to this array or collection. Existing values are not replaced at the moment. This makes it impossible to specify a default other than an empty array or collection… There is an outstanding request to improve this: #216)
Thanks for pointing out that the documentation for this can be improved, I’ll take a look!