I am using the collections library from CVS and did not have a problem with the minor re-factoring. After a few quick cosmetic changes, everything works fine as far as I can tell.

I have placed a couple of UML diagrams on my web site with the code to help explain what I am doing. You can find the files at: http://bblfish.net/java/collections/

The collections.jpg picture is a quick sketch of the current collections.map class hierarchy.  As you can see AbstractHashedMap contains a collection of HashEntry objects. Each of these have a key and a value. Various subclasses of AbstractHashedMap implement different specialisations of hashes, some of which require specialisations of HashedEntry (eg IdentityMap requires an IdentityEntry).
This diagram does not show the inner class relationships. For example HashedEntry is an inner class of AbstractHashedMap.

What I am proposing is really only a very small change. (Even if the next diagram looks very different)

If you looks at collections-altered.jpg you will see that the only novelty is that HashEntry is now an interface, with most of the code that it used to contain now in DefaultHashEntry. I have shown the packages nested inside one another to make clear the static inner class/interface relationships. As you see DefaultHashEntry has three fields, but ReflexiveHashEntry only has two, since it is a data structure that is used for a set where they map.key = map.value.

The only change needed is the interface change - making HashEntry an interface.
This allows us to bypass the default implementation of HashEntry.

I wrote two classes to show how this small interface change can be useful:
	- HashedSet, a class that functions like the java.util.HashSet
	- WeakHashedSet, a class that works like the HashSet from sun but
		where every element is a weak reference.

Henry