commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Baum, Karl" <>
Subject RE: commons cache
Date Wed, 14 Jul 2004 22:12:54 GMT
Forget the gui admin tool.  I agree that's not what commons is about.
That could be an after the fact tool that's not in jakarta commons.  The
point was that a common caching API opens the door to other

I agree, most applications only access the java.util.Map part of the
caching application.  Making the main access point of the cache API
implement Map  might not be a bad idea.  

Of course there are other areas where the major caching implementations
overlap, mainly in regards to administration and the viewing of your
caches.  Obviously if your entire application accessses only the thin
wrapper, changing implementations would be tremendously easier.  On a
project I was on in the past, we wanted to switch between JCS and
EHCache when it was discovered that JCS had several bugs with disk
persistance.  Of course this was near impossible because our
administration tools needed to talk to JCS.

As a side note, I think many of the JCS bugs have been fixed since then.

-----Original Message-----
From: Stephen Colebourne [] 
Sent: Wednesday, July 14, 2004 5:58 PM
To: Jakarta Commons Developers List
Subject: Re: commons cache

> Baum, Karl wrote:
> >[snip]For the most part though, all good caching implementations only
> >expose a get,put, and remove to the application.
> >
> That much of the problem sounds a lot like an implementation of
> java.util.Map to me ...

ie. all thats needed is to get all the caching projects to implement the
interface and there is no need for a commons-caching.

Also, you should know that I wouldn't support developing a web/GUI-based
caching administraion interface in commons. Its not what commons is


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message