how about this caching strategy:
The class java.beans.Introspector is using the Class object as the cache
hashtable key.
This is fine, two Class objects with the same name but with different class
loader do not return true for equals().
If we use that as the key, than one cache can contain all the beans. The
problem becomes when class loaders are created repeatedly, like in the case
of JSP page development. In that case, if the programmers do not call the
clear functions there will be a memory leak.
What java.beans.Introspector is doing is to key by the Class, and have two
flush functions, one for the entire cache, and one for a specific class.
This can work here as well. If we need to flush by a class loader (I don't
think it is necessary, repeated class loading happens only at development
time, there is no real problem in nuking all the cache) it is still possible
to iterate over all the keys and remove those that come from that class
loader.
Another option is to make the cache a WeakHashMap. In that case the class
will eventually expire, and the class loader can be freed.
I am not sure whether WeakHashMap or SoftRefHashMap is more suitable here.
Since we deal with class objects, the issue is much more complicated. The
class org.apache.commons.collections.SoftRefHashMap will not be helpful
here. The cached values will expire, but the keys (the actual Class objects)
stay in the map. In that case the class is still referenced and the
ClassLoader cannot be garbage collected.
java.util.WeakHashMap is also not a sure bet. The weak reference is supposed
to be cleared after all other strong references are cleared. I am not sure
how that can happen with Class Objects. The class loader will maintain a
reference to them. The class loader cannot be released until all the Class
objects are, but they are still reachable through a weak reference (so the
class loader cannot release). This becomes a chicken and an egg problem.
So I think the safest is to use the java.beans.Introspector approach, it
seems the be the safest. I think using the class loader as a key might cause
some unexpected behaviours, because of the parent child relationships of
class loaders. probably the safest thing is to key by class and nuke the
whole cache all together. Class loaders also do not implement hashcode() and
equals(). This also makes them suspects for table keys. (though the Object
class hashcode() and equals() are supposed to be enough in that case).
E
