Declared order of options incorrect when mixing methods and fields

[zegelin]

With @Command(sortOptions = false) the following option definitions don't display in their declaration order:

    @CommandLine.Option(names = "--foo")
    public void something(final boolean value) {}

    @CommandLine.Option(names = "--bar")
    public String bar;

    @CommandLine.Option(names = "--baz")
    public void somethingElse(final boolean value) {}

The help output:

      --bar=<bar>
      --foo
      --baz

Additionally, the following declaration seems to have unpredictable order -- it varies run to run.

    static class FirstMixin {
        @CommandLine.Option(names = {"-e", "--exclude"}, paramLabel = "EXCLUSION", arity = "1..*")
        void setExclusions(final Set<String> values) {}

        @CommandLine.Option(names = {"-g", "--global-labels"}, paramLabel = "LABEL", split = ",")
        public Set<String> globalLabels;

        @CommandLine.Option(names = {"--no-global-labels"})
        public void setNoGlobalLabels(final boolean noGlobalLabels) {}

        @CommandLine.Option(names = {"--no-fast-float"})
        public void setNoFastFloat(final boolean noFastFloat) {}

        @CommandLine.Option(names = {"--enable-per-thread-cpu-times"})
        public boolean perThreadTimingEnabled;
    }

    @CommandLine.Mixin
    FirstMixin firstMixin;

First run help:

-g, --global-labels=LABEL[,LABEL...]

      --enable-per-thread-cpu-times

      --no-global-labels
      --no-fast-float
  -e, --exclude=EXCLUSION...

Second run:

  -g, --global-labels=LABEL[,LABEL...]

      --enable-per-thread-cpu-times

  -e, --exclude=EXCLUSION...

      --no-global-labels
      --no-fast-float

This is with version: 3.6.1

[remkop]

Good find, thanks for reporting it!
Looks like declaration order only works when all options are annotated fields, but the order gets mixed up when annotated methods come into play.

The best way to solve this is to let application authors explicitly specify the order. Perhaps with an index attribute, like this:

@Option(names = “-x”, index = 2) int x;
@Option(names = “-y”, index = 0) int y;
@Option(names = “-z”, index = 1) int z;

I’m open to other suggestions, including a better name than index

[remkop]

Perhaps order is a better name.

[remkop]

Added @Option(order = <int>) attribute to allow explicit control of option ordering in the usage help message.

Pushed to master. Please verify.
This will be in the upcoming 3.9 release.