Každého, kdo četl tu knížku, zaujme něco jiného. Dělám si svoji malou hitparádu a jsem rád, že jste si vybral tu jednoznačnost přístupových modifikátorů. To je má oblíbená kategorie. Vypovídá dost o rozdílu různých pohledů na svět. Co vypadá smysluplně pro normální OOP, má ve světě API zvláštní konsekvence.

Co se týká těch velmi diskutovaných referencí. Tak nejdůležitější, co jsem chtěl říci je, že jsou součástí API. Je rozdíl mezi tím jestli jsou normální či "weak". A samozřejmě souhlasím, že konzistence je důležitá a když už se v JavaBeans specifikaci rozhodli pro normální referenci (oni tedy museli, v té době jiná nebyla), tak by se to mělo obvykle dodržovat.

Nakonec mohu jen dodat, že se zdá, že skutečně existují různé programovací světy. Ne každý nutně píše API pro obecné použití. Téměř každý pracující v týmu však alespoň dává API svým kolegům. Jednou jsem to rozebíral s bratrancem, který se také tvářil, že píše "napiš, vyhoď a přepiš" aplikace pro koncové uživatele. Nakonec však stejně sám rád musel přiznat, že má část kódu, kterou využívá znovu a znovu a u níž dodržuje kompatibilitu.

Hodně štěstí při psaní API a dík za recenzi.

Je tu ale jeden VELKÝ problém: Návrhový vzor Listener (Observer) je zvykem v Javě implementovat BEZ weak-refů. A ve chvíli, kdy je určitý zvyk, je nutné ho dodržet při návrhu API, i kdyby to byl zvyk hloupý. Bohužel to tak je a tím pádem mi nezbývá nic jiného než říct: Listenery by měly být (za normálních okolností) drženy klasickými referencemi (pokud ne, musíte to VÝRAZNĚ zdokumentovat).
Když totiž zaregistrujete listener na JButton pomocí anonymní vnitřní třídy (což se běžně dělá) a ten listener by byl držen Weak-refem, při nejbližším GC by se to uvolnilo a program by se vám choval dost divně.

Co naděláme, je takový zvyk, takže správné API má být podle zvyklostí. Žádné Weak-reference bych tedy nedoporučovala...

A já bych klidně řekl pravý opak. Zjednodušeně řečeno, kdokoliv programuje něco, co budou používat jiní programátoři, navrhuje API. Pokud se takové API nedostane mimo firmu, určitě tolik nezáleží na jeho stabilitě, ale další vlastnosti dobrého API jsou pořád stejně důležité: snadné a intuitivně správné použití, dobrá dokumentace pokrývající i výjimečné stavy, konzistence s ostatními API a tak.

A že by se mi mohla reference na listener sama od sebe ztratit? Pokud budu potřebovat někdy v budoucnosti listener odregistrovat, stejně na něj musím mít referenci. Takže se mi nemůže stát, že mi jej GC z ničeho nic zruší.

Takže weak reference na listener dobře napsanému listeneru neuškodí a tomu špatně napsanému občas může pomoci.

A jak weak reference uchovávat v kolekci a mazat ty neplatné? Snadno -- při procházení kolekce za účelem vyvolání listenerů použiju ListIterator, a když zjistím prázdnou referenci, rovnou ji z kolekce vymažu.