Dlaczego java.util.Properties implementuje Mapę <Obiekt, Obiekt>, a nie Mapę <Ciąg, Ciąg>

Question

Klasa java.util.Properties ma reprezentować mapę, na której klucze i wartości są obydwoma łańcuchami. Dzieje się tak, ponieważ obiekty Properties są używane do odczytu plików .properties, które są plikami tekstowymi.

Dlaczego w Javie 5 dokonali modernizacji tej klasy, aby wdrożyć Map<Object,Object>, a nie Map<String,String>?

W javadoc stany:

Ponieważ właściwości dziedziczy z Hashtable, nakładane i metody putAll można zastosować do obiektu Właściwości. Ich użycie jest zdecydowanie odradzane, ponieważ pozwalają wywołującym wstawiać wpisy, których kluczami lub wartościami nie są łańcuchy. Zamiast tego należy użyć metody setProperty. Jeśli metoda przechowywania lub składowania jest wywoływana w obiekcie "zagrożonym" właściwości, który zawiera klucz lub wartość inną niż String, wywołanie zakończy się niepowodzeniem.

Ponieważ klucze i wartości mają być zarówno ciągi, to dlaczego nie wymusić tego statycznie przy użyciu odpowiedniego rodzaju rodzajowego?

Chyba dokonywania Properties wdrożyć Map<String,String> nie byłby w pełni wstecznie kompatybilne z kodu napisanego dla pre-Java 5. Jeśli masz starszą kod, który przykleja niebędące struny do właściwości obiektu, a następnie, że kod nie będzie już skompilować z Java 5. Ale ... czy to nie jest dobre? Czy cały czas generics nie jest w stanie wychwycić takich błędów typu podczas kompilacji?

Answer 1

Ponieważ zrobili to w pośpiechu we wczesnych dniach Java i nie zdawali sobie sprawy, jakie konsekwencje będą miały cztery wersje później.

Generics miały być częścią projektu Javy od samego początku, ale funkcja została odrzucona jako zbyt skomplikowana i, w tym czasie, niepotrzebna. W rezultacie wiele kodu w standardowych bibliotekach jest zapisanych przy założeniu nietypowych kolekcji.Zajęło prototypowy język "Pizza" od Martina Odersky'ego, aby pokazać, jak można je wykonać dość dobrze, zachowując niemal idealną kompatybilność wsteczną, zarówno z kodem Java, jak iz bajtem kodu. Prototyp doprowadził do wersji Java 5, w której klasy kolekcji zostały doposażone w generyczne w sposób, który pozwalał na kontynuację pracy starego kodu.

Niestety, jeśli były one wstecznie uczynić Properties Dziedzicz Map<String, String>, wówczas po uprzednio ważny kod będzie przestać działać:

Map<Object, Object> x = new Properties() 
x.put("flag", true) 

Dlaczego ktoś miałby to robić poza mną, ale zaangażowanie Sun do wstecznej kompatybilności w Java poszła poza heroizm w bezsens.

Co jest teraz cenione przez większość wykształconych obserwatorów, to, że Properties nigdy nie powinien w ogóle odziedziczyć po Map. Zamiast tego powinien owinąć się wokół Map, ujawniając tylko te cechy Map, które mają sens.

Od czasu wynalezienia Java na nowo, Martin Odersky opracował nowy język Scala, który jest czystszy, dziedziczy mniej błędów i tworzy nowe obszary w wielu dziedzinach. Jeśli znajdziesz irytujące usterki Javy, spójrz na to.

Answer 2

Powód: Liskov substitution principle i kompatybilność wsteczna. Properties rozszerza Hashtable i dlatego musi akceptować wszystkie wiadomości, które zaakceptuje Hashtable - a to oznacza akceptację put(Object, Object). I musi rozszerzyć zwykły Hashtable zamiast Hashtable<String, String>, ponieważ Generics zostały zaimplementowane w sposób zgodny w dół przez type erasure, więc gdy kompilator zrobi swoje, nie ma generycznych.

Answer 3

Kompatybilność wstecz.

Answer 4

Pierwotnie zamierzano, że Properties rzeczywiście rozszerzy się o Hashtable<String,String>. Niestety wdrożenie metod mostowych spowodowało problem. Properties zdefiniowane w ten sposób powoduje, że javac generuje metody syntetyczne. Properties powinien zdefiniować, powiedzmy, metodę get, która zwraca wartość String, ale musi zastąpić metodę, która zwraca Object. Dodana została więc metoda syntetycznego mostu.

Załóżmy, że masz klasę napisaną w złym, starym, 1,4 dniu. Zastąpiłeś niektóre metody w Properties. Ale to, czego nie zrobiliście, jest nadrzędne wobec nowych metod. To prowadzi do niezamierzonego zachowania. Aby uniknąć tych metod mostkowania, Properties rozszerza się o Hashtable<Object,Object>. Podobnie Iterable nie zwraca (tylko do odczytu) SimpleIterable, ponieważ to by dodało metody do implementacji Collection.

Answer 5

one-liner (two-liner żadnych ostrzeżeń) do tworzenia mapy od nieruchomości:

@SuppressWarnings({ "unchecked", "rawtypes" }) 
Map<String, String> sysProps = new HashMap(System.getProperties());