レガシー コードを移行して、サードパーティ ライブラリからの非推奨の警告を少なくしようとしています。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
CLI がいくつかのgstsetValueSeparator(',')
型をサポートできるようにするカスタム区切り文字を定義するためにここで が使用されていることに注意してください (コード スニペットを参照)。,
入力として、次のプログラム引数を使用して 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
私が監督したかもしれないその構築/使用法に違いはありますか?