A weak identity hash map would be faster and more useful than the existing
weak hash map.  The ThreadLocal mechanism shows how well it can be implemented
(very fast in 1.4) and how useful it can be.  I have a similar need but I don't
want to spawn threads just to get the effect.  What I really need is a
WeakIdentityHashMap.





A DESCRIPTION OF THE PROBLEM :
In JDK1.4, we have

* IdentityHashMap: Which ignores hashCode() for the keys and always uses identityHashCode().

* WeakHashMap - which allows "non-intrusive  customer  extension". The Javadoc says:
"This class is intended primarily for use with key objects whose equals methods test for  customer  identity using the == operator".

However, if you have objects which do *not* test like this (e.g. all Collections!), you are out of luck (with the predefined classes).

It would make much sense to also provide a WeakIdentityHashMap which could be used with all keys according to the WeakHashMap documentation.

CUSTOMER WORKAROUND :
Implement your own IdentityWeakHashMap; you cannot use WeakHashMap or IdentityHashMap there - so you must start at a pretty basic level ...
(Review ID: 180535)
======================================================================

N/A

   This is a reasonable RFE.  The interesting question is, could a general purpose WeakIdentityHashMap be as fast as the custom implementation inside ThreadLocal (as of 1.4).

  xxxxx@xxxxx   2001-09-10

At this point, the need for this functionality has been well-established.  (Arguably we should have provided WeakIdentityHashMap rather than WeakhashMap in the first place.)

  xxxxx@xxxxx   2003-01-29
Jason Mehrens writes:

"I hope that if any new Reference Map is added to the JDK it implements 
ConcurrentMap.  The behavior of the weak/soft references exactly align with 
the behavior of the ConcurrentMap.  Allowing null to be added to a reference 
or a ConcurrentMap has ambiguous meanings.  The WeakHashMap methods read 
just like the ConcurrentMap wrt size, isEmpty, equals, hashCode.
The WeakHashMap spec even implies that another thread (g.c)  is using the 
map.

A lot of the RFEs for new reference maps predate the ConcurrentMap.  Maybe 
they will be updated to say ConcurrentMap instead of just Map someday."
Posted Date : 2007-04-02 04:33:17.0

If the method 'static boolean eq(Object x, Object y)' was a 
non-static one, a subclass overriding that method should 
solve the problem (except the usage of eq for keys, see 
comment of bug 4500542)

The mentioned workaround in 4809420 does not consider one 
detail: the 
method hash(Object x) needs a change, too, I think: instead 
of the line
  int h = x.hashCode();
we should replace x.hashCode() by System.identityHashCode
(x) since it is possible - although not common - that the 
hashCode can change over time for one object. The same 
change is needed in the hashCode() method of the inner class 
SimpleEntry, I think (all hashCodes for the Key-Object).
[This message was posted to bug 4809420 and a copy to 
that bug since the latter is closed.]

A google search for 'WeakIdentityHashMap' shows that there already are many implementations:

utilMDE.WeakIdentityHashMap
edu.emory.mathcs.util.collections.WeakIdentityHashMap
org.jboss.util.collection.WeakIdentityHashMap
org.hibernate.search.util.WeakIdentityHashMap
gnu.java.util.WeakIdentityHashMap
org.openrdf.elmo.util.WeakIdentityHashMap

...and there's one at our company, too...

The JBoss and Hibernate implementations are probably identical.

Is there a resolution for this bug?  It's been open for over 5 years now, and should be easy to fix.