オラクルはJDKでのコマンドラインオプションを標準化する道を舗装している

Jonathan Gibbons氏は、オラクルでのJava SE言語のツールのリードであるが、JDKツールにおけるコマンドラインオプションへの一連のガイドラインを導入するためにJEP 293を作った。 これは、コマンドラインオプションの間に存在する差異を修正しようとしている。JEPはまだ対象バージョンを持っていないが、これはもっとも早くてもJava 10で提供されるということを意味する。しかしながら、スコープは新しいオプションへの一連のガイドラインを作ることだけを考慮しており、すでに存在しているオプションを修正しない。これは感じられる効果に対して長過ぎるかもしれない。

JEP自身に示されていることとして、JDKにおける異なるツールは、互いに連携しないコマンドラインオプションを含めて進化してきた。 たとえば、短いオプションは1文字であることがある(モジュールを示す新しい-pオプションのように)。そして1文字より多いこともある(すでに存在するクラスパスを示す-cpオプションのように)。 また、同じオプションがツールに依存した異なる方法で呼び出されるかもしれない。javacでの-versionとpack200での--versionのように(気をつけてほしいのは2つ目の場合ダッシュが2つあることだ)。これはJDKツールの上で動作するユーティリティを作成することを複雑にしており、またコマンドラインオプションについて精通しようとする新しい開発者にとっての追加の障壁を作っている。

この状況を改めるために新しいJEPは新しいコマンドラインオプションへのUNIXスタイルに似た、getopt(3)を主にベースとした一連のガイドラインを作成するだろう。ドキュメントにおいてすべてのセットが利用可能となるが、日々のユーザに関連がある可能性が高いガイドラインは次のようなものだ。

• オプションは長いフォーマットと短いフォーマットを持つべきである。短いフォーマットはダッシュが1つと文字が1つで構成される。長いフォーマットはダッシュが2つと多くの文字と必要ならダッシュで構成される。
• 短いオプションはまとめられる。たとえば-m -kは-mkと同じだろう。
• オプションは任意のパラメータを持つかもしれない。
• ヘルプはすべてのツールで同じ方法で取得できるべきである。

後方互換性の精神に従って、JEPはガイドラインが新しいコマンドラインオプションに適用されなければならないと述べているが、すでに存在するオプションへは必ずしも必要はないとしている。これが意味することは、現在のオプションの一部またはすべてが決して削除されないかもしれないということだ。たとえそれらがガイドラインに合致しないとしてもだ。さらに新しいガイドラインに従ったオプションはすでに存在するオプションと一緒に動作するように提供されるかもしれない。つまり古いコマンドラインオプションと新しいコマンドラインオプションの両方を持つ機能もあるということだ。これは後方互換性と改善の間のよい妥協にように聞こえるが、ディスカッショングループにおいて、解決が困難な曖昧性が結果として発生しているとすでに指摘している人もいる。対話が進む間に、ガイドライン自身がこれらの問題に適応するために修正される可能性がある。