2011-11-10 12 views
1

Javaプロパティのドキュメントは、putメソッドとputAllメソッドの使用を強く推奨していません。私はちょうどプロパティクラスのソースコードを見て、私は少しHashtableのパラメータ化された型が文字列ではなくオブジェクトに設定されて参照してください少し驚いています。下位互換性とは別の理由がありますか?Javaプロパティの修正

if(p1 instanceof String && p2 instanceof String) { 
      return super.put(p1, p2);   
}else { 
      throw new IllegalArgumentException("Invalid argument type"); 
} 

おかげで、

Abidi:また、プロパティは、クラスのように、大体、余分な前提条件(私はそれがLKPの違反だ知っているが、ハッシュテーブルはとにかく悪い選択した拡張)と置くとのputAllメソッドをオーバーライドすることはできません

+3

'Properties'は10年前のジェネリックに先行する古いクラスであり、今では廃止予定のHashtableを継承するように設計されています。通常は 'ResourceBundle'を使って.propertiesファイルを解析し、実行時に値を更新する必要があるときに' Map 'を明示的に設定する方がよいでしょう。 – millimoose

+0

型パラメータStringを作成できなかったのは、実際にプロパティを使用してString以外のオブジェクトを格納するアプリケーションが破損するためです。これはクラスの誤った使用になりますが、JDKの方針は古いコードをコンパイルしないようにすることです。 – millimoose

答えて

1

ほどスマートではなかったと思いますAPIドキュメント)、はいそれは下位互換性のためです。

プリジェネリックJavaでは、値として非文字列を使用してput(key, value)を呼び出すと、Propertiesインスタンスは例外をスローしません(ただし、からgetProperty(key)を返します)。

上記の修正を実装していた場合、同じ呼び出しコードは「より早く失敗する」でしょう。世界中の何百ものJavaアプリケーション&サーブレットが正常に読み込まれず、歯が痛くなります。&

希望に役立ちます。

0

は、私はあなたが言及したように、テストを行うにはもっと良かったはず同意するが、私はそれはかなり迷惑なんだ合意(および不十分で文書のプロパティクラスの作者があなた:)

関連する問題