well i really like that alternate implementation PA mentioned. that's
very complete. but i can't use that because i can't be sure that my
software will always conform to the license.
to answer dmitry's question, yes, i needed a hashtable which used soft
references, not weak references. according to the java docs, soft
references are most appropriate for "memory sensitive caches" which is
exactly what I'm going for.
First, the get method: I think calling remove here could cause you
problems with ConcurrentModificationExceptions if you use an
iterator. The last time I checked, the iterators just call get, and
since the iterators are fail fast, they will fail if calling get
changes the underlying collection. I believe this is why WeakHashMap
only purges gc'd members when a mutator method is called.
Good point. My code doesn't iterate over the elements so I never
thought about this case. I put in that remove() because I figured at
some point my code needs to purge references to gc's objects. I wanted
to use a callback from the SoftRef object but that doesn't seem to be
available. How do auto-managing lists usually handle this case? Maybe
it's acceptable for an iterator to simply throw an exception if i
modify the contents concurrently.
So it returns the number non-null (i.e. non gc'd) elements. I assume
this is because Hashtable is defined to not support null values. This
seems like it could cause you some headaches, however, since other
methods, like keys and keySet will return a different number of
elements.
Well, I thought about overriding keys() to only return keys to non-null
objects, but I couldn't think of an efficient implementation. The
fastest implementation I could think of was N log N (essentially what
purge() does), which seemed to be too slow considering I think keys()
is otherwise constant time. Anyone know an efficient way? I also don't
use this api in my code, but I might in the future so it's one I'd like
to get right.
Also, your elements method will return all the elements, even if they
are null. This is unexepected, given the implementation of the size
method.
See now that's the kind of bug I was talking about. I meant to filter
out null values:
public Enumeration elements() {
Vector v = new Vector();
Enumeration e = super.elements();
while( e.hasMoreElements() ) {
Object o = ((SoftReference)e.nextElement()).get();
if( o != null ) {
v.addElement( o );
}
}
return v.elements();
}
In the end, it might be easier to have size just return the actual
size, and let your implementation return null values.
I guess in some way I wanted to have the size be a representation of
the number of elements I could actually get out of the table. For my
purposes, it would be better for me to override keys(), even if it's
slow. I will update the code and come back to the list with it. Thank
you, Rob.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/java-dev/email@hidden
