The garbage collector. The class comment for WeakHashMap is full
of warnings like this one:
Because the garbage collector may discard keys at any time,
a WeakHashMap may behave as though an unknown thread is silently
removing entries. In particular, even if you synchronize on a
WeakHashMap instance and invoke none of its mutator methods,
it is possible...
In 1.4, they added some sections:
Note that the fail-fast behavior of an iterator cannot be
guaranteed as it is, generally speaking, impossible to make
any hard guarantees in the presence of unsynchronized
concurrent modification.
So they can not _guarantee_ that a CMX is thrown if the GC drops
something from the map during the iteration, but they'll try to.
Yes, didn't read this carefully enough. They seem to be saying that
they cannot guarantee most default behavior of this map due to GC.
Seems like catching the exception and trying again should be enough.
Yes, I've already been thinking about moving the reference tracking
to an extra class. Some of my question had exactly that background.
But there are more important things to be taken care of first, so
I'll let this settle for a while. Except for the volatile/non-polling
stuff. Maybe I'll come up with a patch for 3.1.
Yep, separating is not a high priority.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
