Hey James,
Glad you are finding the cache stuff useful.
> Is there much code that depends on this API yet.
> Can we tweak the API somewhat without burdening
> people with excessive maintenance?
Yes and no. We have a fair amount of code that uses this in a different
packaging scheme, but not that uses the org.apache.* version. I don't have
any issues with tweaking the API, in fact I think some tweaking is
warranted.
> I'd prefer a few method names to closer reflect
> the Java Collections Framework naming for consistency
Agreed.
> a size() method to return the number if items in the
> cache would be useful
Agreed. The CacheStat stuff sort of supports that, but its pretty poorly
conceived. The initial intention was that not every cache is going to know
how many objects it is storing, but those could just return -1 or throw an
exception.
> some mechanism for iterating through the current cache
> contents, getting an iterator through the keys or something
> of that ilk would be useful.
Agreed. There is a getKeysForGroup method that will return the items in a
specific group, but currently no way to iterate through every key or value.
> What do you think about relaxing the prerequisite that all
> keys and values in the cache must be Serializeable?
I had originally set it up as you describe, and then switched to just having
everything Serializable since that was simple and met our needs. Moving
back the other way should not be hard. The "not storable" response and
StashPolicy mechanisms may be helpful here.
> I'd like a method like the put() method from Map
> but
> (i) the previous value is returned rather than a true /
> false indicator of whether this new value was stored.
> I can't see to many application developers caring too
> much whether store() actually stores the object or not.
> Do you have a specific need for this boolean?
Not that I can recall.
> (ii) the values of the expiry and cost arguments
> come from the cache themselves rather than the
> application programmer. Defaults could be applied
> to a particular cache (region) via a config file
> or whatever. Often an application developer doesn't
> know what these values are
I have no issues with defaults, but I would argue that it should be the
application program who defines these values. (I think you're saying the
same thing, we'd just need a default for the Map-ish case.)
> Similarly I'd like the remove() method to return the
> previous value that was in the cache or null if there is
> nothing cached for the key, to be similar to the
> Map.remove(key) method.
Retrieving an object from the cache may be significantly more expensive than
just removing it or checking if it exists. I'm OK with this as long as
there is a plain remove-and-don't-retrieve method as well, maybe Object
remove(Object key, boolean retrieve), which always returns null if retrieve
is false?
Feel free to dig in and make changes. If I didn't think this needed a fair
amount of work, I would have proposed it for commons proper already.
