Umieszczanie obiektów w java.util.Properties

Question

Próbuję zrozumieć, dlaczego java.util.Properties została zaimplementowana w ten sposób. Ma dwa interfejsy: getProperty/setProperty, które akceptuje tylko łańcuchy i put/get, które akceptuje dowolny obiekt jako wartość. Te dwa interfejsy wydają się nakładać, więc ciąg dodany za pomocą funkcji put() może zostać pobrany za pomocą metody getProperty().

Wygląda na to, że z tym dziwnym interfejsem hybrydowym występują pewne problemy. Umieszczenie obiektu, który przesłania właściwość ciągu, powoduje efekt uboczny usuwania wartości ciągu, tworząc wartość null jako wynik getProperty. Dodanie liczby całkowitej lub innej wartości, która ma proste tłumaczenie ciągu znaków, może być źle rozumiane jako wartość nieruchomości (ale jako właściwość zawsze ma wartość NULL).

Moje pytanie brzmi: czy istnieje prawdziwy, praktyczny powód tego? A może jest to na wpół wypalona implementacja, jak podejrzewam?

Answer 1

Joshua Bloch wspomina o tym wyraźnie w Effective Java

[rozdziału 4] W przypadku Properties projektanci zamierzeniu jedynie ciągi zostać dopuszczone klucze i wartości, ale bezpośredni dostęp do leżącej Hashtable pozwala ten niezmiennik, który zostanie naruszony. Po naruszeniu tego niezmiennika nie można już korzystać z innych części interfejsu API właściwości (load i store). Do czasu znalezienia tego problemu było już za późno, aby go poprawić, ponieważ klienci polegali na użyciu kluczy i wartości nie związanych.

Ten tekst dotyczy kontekstu używania kompozycji nad dziedziczeniem. Zasadniczo używa tego jako przykładu, kiedy należy używać kompozycji zamiast dziedziczenia. Jeśli Properties owinąłby jeden Map zamiast jednego, mógłby wymusić nieuruchomienie użycia String jako kluczy i wartości.

Tak więc odpowiedź brzmi: To było przeoczenie.

Answer 2

Oficjalne dokumentacje mówi

Ponieważ właściwości dziedziczy z Hashtable, put 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. Podobnie wywołanie metody propertyNames lub list nie powiedzie się, jeśli zostanie wywołane w obiekcie "zagrożonym" właściwości, który zawiera klucz inny niż String.

http://docs.oracle.com/javase/8/docs/api/java/util/Properties.html

Answer 3

Dostęp do put i get jest wynikiem Properties będąc przedłużeniem Hashtable, a dwie metody nie powinny być używane (ale nie może być ukryte z realizacji ze względu na ich publicznego dostępu w nadrzędnej).

Javadocs miłego notatkę o tym, dlaczego nie powinno się stosować te same metody i powinno zamiast tylko używać łańcuchów:

Ponieważ Properties dziedziczy z Hashtable sposoby put i putAll mogą być stosowane do Properties obiekt. Ich użycie jest zdecydowanie odradzane, ponieważ pozwalają wywołującemu wstawiać wpisy, których klucze lub wartości nie są Strings. Zamiast tego należy użyć metody setProperty. Jeśli metoda store lubzostanie wywołana w "zagrożonym" obiekcie o wartości Properties, który zawiera klucz lub wartość innego niż , wywołanie zakończy się niepowodzeniem. Podobnie wywołanie metody propertyNames lub list nie powiedzie się, jeśli zostanie wywołane na "zagrożonym" obiekcie o nazwie Properties, który zawiera klucz inny niż String.

Jak @yshavit zauważa, że ​​to więcej sensu dla Properties przedłużyć Hashtable<String, String> niż hashtable dwóch obiektów, ale to było prawdopodobnie decyzja podjęta w celu utrzymania kompatybilności wstecznej, jak wszelkie programy używając get/put z dowolnego obiekty inne niż String zostałyby uszkodzone przez taką zmianę.

Answer 4

Z Java Docs

Ponieważ właściwości dziedziczy z Hashtable, put i metod putAll można zastosować do obiektu Właściwości.Ich użycie jest odradzane, ponieważ pozwalają wywołującemu wstawiać wpisy, których klucze lub wartości nie są ciągami. Zamiast tego należy użyć metody setProperty. Jeśli metoda przechowywania lub składowania zostanie wywołana na obiekcie "zagrożonym" Właściwości: , który zawiera klucz lub wartość inną niż String, wywołanie zakończy się niepowodzeniem. W podobny sposób wywołanie metody propertyNames lub listy nie powiedzie się, jeśli zostanie wywołane w obiekcie "zagrożonym" właściwości, który zawiera klucz inny niż String, o numerze: .

Answer 5

Properties rozciąga Hashtable, dzięki czemu można używać Properties wszędzie można użyć Hashtable.

Klasa Hashtable to miejsce, z którego pochodzą funkcje get() i put().

Answer 6

put(key, value) i get(key) są resztą wątpliwej decyzji o przedłużeniu PropertiesHashtable. To zachowanie nie może być zmienione, ponieważ złamie kompatybilność wsteczną, ale jakikolwiek przyzwoity przewodnik po stylach, w tym sam dokumentacja API, zaleci, aby nigdy nie używać tych metod.

Answer 7

Jak powiedzieli inni, należy go używać tylko dla Strings. Istnieją sposoby serializacji obiektu jako łańcucha znaków i jego pobierania, ale oczywiście nie jest to przeznaczone do tego celu. Rozumiem, że to naprawdę denerwujące, ponieważ jest najbliżej tego, jak można uzyskać wieloplatformowy sposób zapisywania i pobierania danych aplikacji. O ile mi wiadomo, nie ma oficjalnego sposobu na zapisywanie rzeczy innych niż ciągi w folderze, który jest ukryty przed użytkownikiem, mimo że większość systemów operacyjnych ma katalogi appdata.