> > Immutable ma się tu jak pięść do nosa. Sens istnienia WeakHashMap jest
> > w zmienności -
> > usuwane są z niej klucze, które GC zbierze.
>
> Nie napisałem, ze WeakHashMap jest immutable, tylko że bezpieczeństwo
> przy wielu wątkach jest związane z brakiem zapisów.
>
> > To czy get jest operacją modyfikującą jest szczegółem implementacji.
>
> To trochę daleko posunięta teza. W dodatku sprzeczna z książką, którą
> polecał A.L. i w której pokazano, jak można opakować HashMapę w klasę,
> która eksponując tylko get() jest bezpieczna.

Ale co to ma wspólnego z dyskusją na temat WeakHashMap?

> > Istotne jest, że w pewnym momencie jakiś obiekt zawarty w WeakHashMap
> > jest "weakly reachable". Można więc "go" usunąć z mapy.
> > Skąd wiadomo, że jest "weakly reachable"? - zaglądamy do dokumentacji
> > WeakReference:
>
> I co - jest tam coś o WeakHashMap.get?
>
> Skąd pomysł, że get() konsumuje kolejkę referencji? Dlaczego nie put
> ()?
> Nie wydaje Ci się, że put() byłby bardziej odpowiednim kandydatem,
> skoro i tak jest już logicznie modyfikatorem?
> Tak czy inaczej - nawet jeśli get() stymuluje czyszczenie mapy, co z
> programem, który nie woła get()?

wszystko jest w dokumentacji:

"Because the garbage collector may discard keys at any time, a
WeakHashMap may behave as though an unknown thread is silently
removing entries. In particular, even if you synchronize on a
WeakHashMap instance and invoke none of its mutator methods, it is
possible for the size method to return smaller values over time, for
the isEmpty method to return false and then true, for the containsKey
method to return true and later false for a given key, for the get
method to return a value for a given key but later return null, for
the put method to return null and the remove method to return false
for a key that previously appeared to be in the map, and for
successive examinations of the key set, the value collection, and the
entry set to yield successively smaller numbers of elements."

PL