私が参加または開始するすべてのJavaプロジェクトには、常に依存関係としてcommons-langがあるようです-そしてそれには正当な理由があります。commons-lang には、他の言語の最も標準的な API を備えたかなり標準的なクラスとユーティリティ メソッドが多数あります。Sun/Oracle/JCP が commons-lang の一部を標準 API に採用しなかったのはなぜですか?
2 に答える
5
すでに指摘したように、コモンズ API の一部の機能は Java になり、多くの場合、元々のコモンズ ライブラリよりも優れた実装 (IMHO) になっています。列挙型は典型的な例です。
Commons-lang を採用しない理由については、一部のクラスでは混乱の要素があります。StrBuilder を例にとると、Java の StringBuilder よりも強力で、拡張可能です。しかし、そのようなクラスを Java コア API に追加するかどうかはわかりません。StringBuilder/StringBuffer は、ほとんどの目的に対して完全に十分であり、そこに別のクラスを含めると、少し混乱するだけです。既存のコードが壊れる可能性があるため、すべての変更に対応する方法で StringBuilder を実際に変更することはできませんでした。追加したとしても、他の誰かが別のより強力なバージョンを追加した場合はどうなりますか? StrBuilder2? やがてすべてが大混乱になります (そのような追加は言うまでもなく、コア API はすでに存在していると主張する人もいます)。
そしていつものように、大きなポイントはcommons-lang から何を含めるべきかということです。MutableXXX クラスが追加されることを望む人もいれば、XXXUtils クラスが追加されることを望む人もいれば、time パッケージが必要な人もいるでしょう。
もう 1 つの重要な点は、Java 開発者は、Apache 開発者が commons-lang に対して行っているよりも、コア Java API の内容に注意を払う必要があるということです。commons-lang のくだらない設計が将来のリリースで取って代わられた場合、古い設計は非推奨になり、その後削除される可能性があります (実際にこれが起こるようです)。より混乱。
commons-lang の機能をもっと含めるべきだと思いますが、その価値はあると思います。少なくとも部分的には、そうでない理由がわかりました。
于 2011-01-29T17:31:07.887 に答える
1
歴史的に、Apache Commons は、列挙型や注釈など、後に Java 5 で導入された機能の一部を実装していました。それらの実装は、統合を困難にするほど十分に異なっていました。
于 2011-01-29T15:31:09.087 に答える