Почему определенные параметры CLI отличаются при использовании DefaultParser вместо GnuParser?

Я собираюсь перенести некоторый старый код, чтобы содержать менее устаревшие предупреждения от сторонних библиотек. Для библиотеки Apache commons-cli (версия: 1.3.1) Я обнаружил в официальном JavaDoc , что GnuParser устаревший и DefaultParser следует использовать вместо:

@deprecated с 1.3, используйте {@link DefaultParser} вместо

Однако следующий фрагмент кода перестает работать как ожидалось:

Options options = new Options();    
Option optionGSTypes = new Option(
        "gst","gs-types", true,
        "the supported types, comma-separated: article, category, template, all");
optionGSTypes.setArgs(3);
optionGSTypes.setValueSeparator(',');
options.addOption(optionGSTypes);

// ... other options

// parsed option values are correct, yet this is deprecated
CommandLineParser parser = new GnuParser(); 
CommandLine commands = parser.parse(options, args);

// ... interpret parsed 'commands' and related actual values via CLI

Обратите внимание, что setValueSeparator(',') используется здесь для определения пользовательского разделителя char ,, чтобы позволить CLI поддерживать sevaral gst-типы (см. фрагмент кода).

В качестве входных данных для вызова CLI используются следующие аргументы программы:

java -jar MyCLI.jar -gst category -gsd 4

Очевидно, что после параметра gsd также может быть добавлено несколько других аргументов. Ожидаемые и правильно разобранные параметры для использования аргумента "gst" без разделителя (через GnuParser):

• "категория" (и ничего больше)

Однако, когда я меняю свой код и переключаюсь на рекомендуемый синтаксический анализатор через:

CommandLineParser parser = new DefaultParser();

результирующие, проанализированные значения обнаруживаются некорректно как:

• "категория"
• "- GSD"
• "4"

Подсказка: я использовал отладчик, чтобы проверить неверный результат процесса синтаксического анализа, проверив поле values в org.apache.commons.cli.Option с помощью возвращаемой переменной commands.

Мое ожидание будет состоять в том, что внутреннее изменение анализатора должно не давать разные результаты, так как это нарушает существующий код. Кто-нибудь сталкивался с тем же поведением с Apache Commons-CLI при переключении на DefaultParser и несколькими значениями параметров и пользовательскими разделителями?

Есть ли разница в конструкции/использовании DefaultParser, которую я мог бы контролировать?

Ответы

private boolean isShortOption(String token)
{
    // short options (-S, -SV, -S=V, -SV1=V2, -S1S2)
    return token.startsWith("-") && token.length() >= 2 && 
           options.hasShortOption(token.substring(1, 2));
}