[concurrency-interest] Optimizing unmodifiableXXX

Osvaldo Pinali Doederlein osvaldo at visionnaire.com.br
Mon Mar 5 20:35:50 EST 2007


Martin Buchholz escreveu:
> Osvaldo wrote:
>
> *Idea: the Collections.unmodifiableXxx() methods could embed the
> intelligence of my utility: if the received collection is empty or a
> singleton, unmodifiableXxx() could return an instance of the optimized
> empty/singleton class, rather than always creating an instance of the
> CollectionsUnmodifiableXxx class. This optimization only requires that
> **unmodifiableXxx() implement an additional switch structure like the
> code above. The result also avoids memory allocation for empty
> collections. As far as I can see, there is no compatibility issue...
> except for a strawman case like code that expects that for any c1 and
> c2, unmodifiableXxx(c1) != **unmodifiableXxx(c2)** even if
> c1.equals(c2), a requirement that's especially absurd for immutable
> collections.*
>
> I think this won't work, since the underlying map may be mutable.
>
> Unmodifiability is not immutability.
>   
Um, only now I saw the problem - the fact that unmodifiableXxx() 
wrappers are synchronized with the underlying collections... damn. I 
knew that fact but since my personal usage pattern is always using these 
methods (as well as singletonXxx() etc) in front of immutable data, it 
seems my little green cells started to hide that unwanted feature of 
unmodifiableXxx() under the rug. Sorry. My idea would require a new API 
with the desired semantics.

A+
Osvaldo

-- 
-----------------------------------------------------------------------
Osvaldo Pinali Doederlein                   Visionnaire Informática S/A
osvaldo at visionnaire.com.br                http://www.visionnaire.com.br
Arquiteto de Tecnologia                          +55 (41) 337-1000 #223




More information about the Concurrency-interest mailing list