PropertiesDefaultProvider fails with static ArgGroup class

[deining]

Minimum example:

Java source file:

1  package test;
2
3  import java.io.File;
4
5  import picocli.CommandLine;
6  import picocli.CommandLine.ArgGroup;
7  import picocli.CommandLine.Command;
8  import picocli.CommandLine.Option;
9  import picocli.CommandLine.PropertiesDefaultProvider;
10
11 public class ArgGroupPropertiesDefaultProvider {
12
13     public static void main(String... args) {
14
15     CommandLine cmd = new CommandLine(new MyCommand());
16     File defaultsFile = new File("MyCommand.properties");
17     cmd.setDefaultValueProvider(new PropertiesDefaultProvider(defaultsFile));
18     cmd.execute(args);
19     }
20 }
21
22 @Command( name="myCommand")
23 class MyCommand implements Runnable {
24
25     @Option(names = "-x")
26     int x;
27
28     @ArgGroup()
29     MyArgGroup anArgGroup;
30     //MyArgGroup anArgGroup = new MyArgGroup(); // this does work!
31    
32    static class MyArgGroup {
33         @Option(names = { "-y" }, descriptionKey= "myOption")
34         static int y;
35    }
36
37    
38     public void run() {
39         System.out.println("Option x is picked up: " + x);
40         System.out.println("Option y inside arg group is not picked up (static class!): " + MyArgGroup.y);
41     }
42 }

Associated properties file (MyCommand.properties):

myCommand.x=6
myCommand.y=9
myCommand.myOption=9

If you comment out line 29 and uncomment line 30, the value from the properties file is picked up.

Is this the intended behaviour?

[remkop]

Thank you for raising this! I’ll investigate when I get to my PC.

[remkop]

I have only had a chance to look at this for a few minutes, but I’m guessing that this is related to the fact that default values in general are not applied to ArgGroups until at least one option in the group is matched.

https://picocli.info/#_default_values_in_argument_groups

[remkop]

If the class associated with the arg group is not a static class, the value from the properties file is picked up.

How can I reproduce this? If I make inner class MyArgGroup non-static, the static int y field gives a compilation error: "modifier 'static' is only allowed in constant variable declarations".
And even if I make MyArgGroup a top-level class (and keep static int y; field as static), there is no default value assigned to MyArgGroup.y... So I did not understand your comment above.

However, I believe the observed behaviour is the expected behaviour: picocli will not instantiate a MyArgGroup and assign default values to the group's options unless at least one of the options of the group is matched on the command line. If a group has multiplicity = "1" it is mandatory and in that case the business logic in the run/call method can safely assume that anArgGroup is non-null, but it should not assume that if the group has the default multiplicity = "0..1".

I understand this may not be intuitive for many users but I cannot imagine how it could work otherwise.

[deining]

How can I reproduce this?

Sorry for not being clear here. I edited my inital posting to make it clear and unambigous. Hopefully I succeeded in doing so.

[remkop]

Thanks for the clarification.
The short answer is that yes, this is working as intended. (see the if (arg.scope().get() != null) check on CommandLine.java line 11222)

Basically, if the application has instantiated the @ArgGroup-annotated field, then picocli should apply defaults before parsing the command line arguments.

If the application has not instantiated the the @ArgGroup-annotated field, then picocli should only instantiate (and apply defaults) when one of the options in that group is matched on the command line. In this case, applications can check that the group was matched on the command line by checking if the @ArgGroup-annotated field is non-null.

[MadFoal]

@remkop This issue is also closed by PR 1446, correct?

[remkop]

@remkop This issue is also closed by PR 1446, correct?

It is the same underlying mechanism, yes. (
The source of default values does not matter.) 😅

Oh, I see what you mean now: can this issue be closed now that we improved the documentation?
Yes, I agree, that is fine.