このjava.util.Propertiesクラスは、キーと値が両方とも文字列であるマップを表すことを目的としています。これは、オブジェクトがテキスト ファイルであるファイルPropertiesを読み取るために使用されるためです。.properties
では、なぜ Java 5 ではこのクラスを を実装するように改造しMap<Object,Object>、 を実装しないようにしたのでしょうかMap<String,String>?
のjavadoc状態:
Properties は Hashtable から継承されるため、put メソッドと putAll メソッドを Properties オブジェクトに適用できます。これらのメソッドを使用すると、呼び出し元がキーまたは値が文字列ではないエントリを挿入できるため、これらのメソッドの使用は強く推奨されません。代わりに、setProperty メソッドを使用する必要があります。文字列以外のキーまたは値を含む「侵害された」Properties オブジェクトで store メソッドまたは save メソッドが呼び出されると、呼び出しは失敗します。
キーと値は両方とも文字列であるはずなので、適切なジェネリック型を使用してそれを静的に強制してみませんか?
Properties実装すると、Java 5 より前のバージョン用に記述されたコードとの完全な下位互換性がなくなると思いますMap<String,String>。文字列以外の値を Properties オブジェクトに挿入する古いコードがある場合、そのコードは Java 5 ではコンパイルされなくなります。しかし、それは良いことではないでしょうか。ジェネリックの目的は、コンパイル時にこのような型エラーをキャッチすることではないでしょうか。
ベストアンサー1
なぜなら、Java の初期の頃に急いでそれを行ったため、4 バージョン後の結果がどうなるかがわからなかったからです。
ジェネリックは当初から Java の設計の一部であるはずでしたが、その機能は複雑すぎるうえ、当時は不要だったため削除されました。その結果、標準ライブラリの多くのコードは、ジェネリックではないコレクションを前提として書かれています。Java コードとバイトコードの両方で、ほぼ完全な下位互換性を維持しながら、ジェネリックをかなりうまく実行できることを示したのは、Martin Odersky のプロトタイプ言語「Pizza」でした。このプロトタイプは Java 5 につながり、コレクション クラスはジェネリックで後付けされ、古いコードが引き続き機能できるようになりました。
残念ながら、遡及的に を継承するとProperties、Map<String, String>以前は有効だった次のコードが機能しなくなります。
Map<Object, Object> x = new Properties()
x.put("flag", true)
なぜそんなことをするのか私には理解できませんが、Sun の Java の下位互換性への取り組みは、英雄的というレベルを超えて無意味なものになっています。
現在、ほとんどの知識豊富な観察者が理解していることは、Propertiesは から継承されるべきではなかったということですMap。 は をラップしてMap、意味のある Map の機能のみを公開する必要があります。
Java を再発明して以来、Martin Odersky 氏は、よりクリーンで、より少ない間違いを継承し、多くの分野で新境地を拓く新しい Scala 言語の開発に取り組んできました。Java の欠点に悩まされている方は、ぜひ試してみてください。