Hi Thomas,
Thomas Neidhart wrote:
[snip]
> Anyway, the logic in WeakHashtable is flawed, as it relies on the queue
> to purge elements from the table. When considering for example the
> elements method:
>
> public Enumeration elements() {
> purge();
> return super.elements();
> }
>
> This purges any elements whose key is put into the queue and then
> delegates to super.elements. When a key that has already been gc'ed
> (Reference.getKey == null), but not yet been put on the queue, the
> corresponding WeakKey is still contained in the map, and thus,
> super.elements() will return this element.
>
> Other methods like keySet also check if the referent of the
> WeakReference is null and omit such entries from the reply, thus leading
> to different results, leading to different results than e.g. size().
>
> In logging, there are 5 methods from WeakHashtable used:
>
> * get
> * put
> * remove
> * elements
> * clear
>
> The only problematic one being elements, and it is used to release all
> registered factories, so this should be safe imho.
>
> We could change the purge method to not rely on the queue, but always
> iterate over the entrySet and remove the entries whose referent key is
> null and update the testcase to ignore the queue?
The implementation does the right thing using the queue. IMHO are all the
tests problematic that try to force the GC, because they make (invalid)
assumptions about the GC strategy of the JDK.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
