anchor.diff:  options   : [AAA, BBB]
   ----
   
  -To support mixing options with positional parameters, the parser has changed. From picocli 2.0, multi-value options (array, list and map fields) are **not greedy by default** any more.
  -
  -To illustrate the new non-greedy behavior, consider this example:
  -
  -[source,bash]
  -----
  -$ java MixDemo -o 1 2 3
  -----
  -
  -Previously, the arguments following `-o` would all end up in the `options` list. Running the above command with picocli 1.0 would print out the following:
  -
  -[source,bash]
  -----
  -# picocli-1.0.1
  -$ java MixDemo -o 1 2 3
  -
  -positional: null
  -options   : [1, 2, 3]
  -----
  -
  -From picocli 2.0, only the first argument following `-o` is added to the `options` list, the remainder is parsed as positional parameters:
  -
  -[source,bash]
  -----
  -# picocli-2.0.3
  -$ java MixDemo -o 1 2 3
  -
  -positional: [2, 3]
  -options   : [1]
  -----
  -
  -To put multiple values in the options list in picocli 2.0, users can specify the `-o` option multiple times:
  -[source,bash]
  -----
  -$ java MixDemo -o 1 -o 2 -o 3
  -
  -positional: null
  -options   : [1, 2, 3]
  -----
  -
  -The 2.0 release notes mention a few other https://github.com/remkop/picocli/releases/tag/v2.0.0#2.0-breaking-changes[potential breaking changes].
  +To support mixing options with positional parameters, the parser has changed. From picocli 2.0, multi-value options (array, list and map fields) are **not greedy by default** any more. The 2.0 release notes describe this change and other https://github.com/remkop/picocli/releases/tag/v2.0.0#2.0-breaking-changes[potential breaking changes] in detail.
   
   == Discovering Collection Types
   
   Picocli performs http://picocli.info/#_strongly_typed_everything[automatic type conversion] of command line arguments to the type of the annotated field.  Both named options and positional parameters can be strongly typed.
   
  -image:http://picocli.info/images/binoculars.jpg[]
  -
  -Prior to v2.0, type conversion worked automatically for arrays and for single-value types like `int` or `java.io.File`, but for `Collection` and `Map` fields picocli required the `type` attribute to be able to do the type conversion:
  +image:binoculars.jpg[]
  +
  +Prior to v2.0, type conversion worked automatically for arrays and for single-value types like `int` or `java.io.File`, but for `Collection` and `Map` fields, picocli required the `type` attribute to be able to do the type conversion:
   
   
   [source,java]
  
positive.code: * CommandLine::populateCommand
  
  
  == Usage Help Format Improvements
  This release contains various bugfixes that improve the usage help format for multi-value options and collections.
  For example, for Maps that don't have a `paramLabel`, picocli now shows key type and value type instead of the internal Java field name.
  
  == Better Subcommand Support
  
  This release adds new `CommandLine::parseWithHandler` methods. These methods offer the same ease of use as the `run` and `call` methods, but with more flexibility and better support for nested subcommands.
  
  // image:https://www.intersoft.no/wp-content/uploads/2015/11/duplicate.png[]
  image:http://picocli.info/images/strong_leadership.jpg[]
  
  Consider what an application with subcommands needs to do:
  
  1. Parse the command line.
  2. If user input was invalid, print the error message and the usage help message for the subcommand where the parsing failed.
  3. If parsing succeeded, check if the user requested usage help or version information. If so, print the requested information and exit.
  4. Otherwise, execute the business logic. Usually this means executing the most specific subcommand.
  
  Picocli provides some building blocks to accomplish this, but it was up to the application to wire them together. This wiring is essentially boilerplate and is very similar between applications. For example, previously, an application with subcommands would typically contain code like this:
  
negative.code:     // 2. handle incorrect user input for one of the subcommands
      // 3. automatically print help if requested
      // 4. execute one or more subcommands
      new CommandLine(new YourApp()).parseWithHandler(new RunLast(), System.err, args);
  }
  ----
  
  The new convenience method is `parseWithHandler`. You can create your own custom handler or use one of the built-in handlers. Picocli provides handler implementations for some common use cases described below.  All of these implement automatic help: if the user requests usageHelp or versionHelp, the requested information is printed and the handler returns without further processing.
  
  The built-in handlers are `RunFirst`, `RunLast` and `RunAll`:
  
  * `RunFirst` only runs the *first*, top-level, command (if it implements Runnable or Callable) and ignores subcommands.
  * `RunLast` only runs the *most specific* subcommand. For example, if the user invoked `java Git commit -m "commit message"`, and `commit` is a `Callable` subcommand, only `Commit::call` is invoked. `RunLast` is now used internally by picocli to implement the existing `CommandLine::run` and `CommandLine::call` convenience methods.
  * `RunAll` invokes `run` (or `call`) on the *top-level command and all subcommands* that appeared on the command line (if they implement Runnable or Callable).
  
  There is also a `parseWithHandlers` method, which is similar but additionally lets you specify a custom handler for incorrect user input.
  
  
  === Improved `run` and `call` Methods
  