XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

> hashcodes do not map 1 to 1 to objects; more than one object may  
> have any given hashcode.

Sure.

> you need a strategy to deal with the possible conflict.
> this could violate the first xom Design Goal, Absolutely correct.

Where's the problem? the hashCode() and equals() impl work exactly as  
intended, hash business as usual. There's no bug.

> one could also have flyweight namespaces, uri and prefix; and  
> flyweight qnames, flyweight namespace and local name.

Sure, doing it on (prefix, localName, URI) gives the largest scope  
for memory footprint reduction.

> setPrefix, setURI, setName, setLocalName are all complicated by  
> flyweight qnames.

They are not significantly more complicated, IMHO. It's always the  
same simple pattern (and it's commonality can be factored out).

> what is the garbage collection strategy?  the qnames will remain in  
> the hashmap even after all other references have disappeared.

Yep they remain in there, but only the most recently used 256 qnames  
since the map is bounded. One might better use 128, but in any case  
it does not appear to be a problem.