[picocli WARN] Could not set initial value for field boolean

[codexetreme]

Hello all, loving picocli so far, its quite simple and above and beyond my expectations, but as all things human, I have reached a point where I am getting into a very complicated cli setup, and need some ArgGroup magic, but I am facing the following issue:

assume I have a simple example like this:

@Command(name = "list",
        mixinStandardHelpOptions = true,
        description = "list all signals")
public class ListSignals implements Callable<Integer> {

    @ArgGroup(exclusive = true, multiplicity = "1")
    SearchFilterArgs searchFilterArgs;

    @Override
    public Integer call() throws Exception {
        return ReturnCodes.NOT_IMPLEMENTED;
    }

    static class SearchFilterArgs {
        @Option(names = {"-A", "--all"}, required = true)
        boolean getAllSignals;
        @Option(names = {"-m", "--message-name"}, required = true)
        String messageName;
    }
}

and my test is as so

@Test
    void checkHelpRender(){
        cmd = new CommandLine(new ListSignals());
        cmd.execute("--help");
        System.out.println("===");
        cmd.execute();
        System.out.println("===");
        cmd.parseArgs("-A");
    }

I am getting the following warning:

[picocli WARN] Could not set initial value for field boolean com.example.ListSignals$SearchFilterArgs.getAllSignals of type boolean to null: ....

can someone please tell me if this is intentional, and if so, how do I suppress the warning ?

PS: I tried the defaultValue in the option annotation , didn't work

[remkop]

@codexetreme Thank you for raising this.
This sounds like a bug. Let me investigate...

[codexetreme]

Sure, let me know if can help out in anyway

[remkop]

I don't have a fix yet, but it can be reproduced when:

• the command has an ArgGroup
• the CommandLine instance is reused for multiple invocations of execute or parseArgs
• the first invocation does not instantiate/initialize the @ArgGroup-annotated field (still need to analyze this further)

There are two workarounds:

1. Initialize the arg group

Currently the @ArgGroup-annotated field is declared but not initialized, so picocli needs to create an instance and initialize that field when an option in the group is matched.

If the application initializes the field, the problem will go away. For example:

public class ListSignals implements Callable<Integer> {

    @ArgGroup(exclusive = true, multiplicity = "1")
    SearchFilterArgs searchFilterArgs = new SearchFilterArgs(); // <--- initialize at declaration
...

2. Create new CommandLine instance for every invocation

Another workaround is to not reuse the CommandLine instance:

@Test
    void checkHelpRender(){
        cmd = new CommandLine(new ListSignals());
        cmd.execute("--help");
        System.out.println("===");

        cmd = new CommandLine(new ListSignals()); // <--- new instance
        cmd.execute();
        System.out.println("===");

        cmd = new CommandLine(new ListSignals()); // <--- new instance
        cmd.parseArgs("-A");
    }

---

Still investigating the underlying cause.
Interestingly, executing with --version instead of --help (as the first invocation) does not reproduce the issue.
I will update again when I know more.

[remkop]

The underlying cause is that with options in an ArgGroups where the group has not been instantiated, the initial value of these options is cached. The bug is that the initial value is marked as "cached", even though it could not be determined and still null (because the enclosing ArgGroup object was still null). The next invocation, picocli sees that the initial value has been marked as "cached", so it tries to apply this value, but this value is still null and null cannot be applied to primitive type variables.

The fix is to only mark the initial value as "cached" when it could be determined successfully.

This has been fixed in master, and the fix will be included in the next release.
Thank you again for raising this!