我即将迁移一些遗留代码以包含来自3rd方库的较少弃用的警告。对于 Apachecommons-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(',')
此处用于定义自定义分隔符,
,以使 CLI 支持多种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
我的期望是解析器的内部更改不应产生不同的结果,因为这会破坏现有代码。DefaultParser
在切换到多个选项值和自定义分隔符时,是否有人遇到过与 Apache Commons-CLI 相同的行为?
DefaultParser
我可能监督的构造/使用有什么不同吗?