What you point out are really 1) a backward compatibility problem and 2) a
standard problem.
For (1), what we can do is to
i)Cut a release version of the JCS impl that conform to the use of Object,
so an existing system already using them will not break.
However, such system will be using BUT the most trivial implementation of
the caching system, ie in-memory cache which discards overflow. Should such
system be configured to use more advanced features, the code will break
anyway during runtime, and therefore requires code modification to use the
Serializable data type.
ii)For all future releases, use Serializable as the signature. If an
existing system does not need any advanced use of caching, it basically
doesn't need to upgrade to the later releases. If it does, it needs to use
Serializable anyway.
For (2), if a standard is not good, it should be changed. Otherwise, it
won't scale up and will ultimately disappear/become pointless. The original
design of the use of Object in the signature reflects a lack of foresight
and is only appropriate/applicable in the most trivial cases.
Hanson
-----Original Message-----
From: Daniel Rall
To: Hanson Char
Cc: 'Turbine JCS Developers List '; ''John McNally ' '
Sent: 7/22/2002 5:45 PM
Subject: Re: [patch] simple patches
Hanson Char <[EMAIL PROTECTED]> writes:
> "In-memory cache which simply discards overflow" is the ONLY case,
> which is not a good case as it suffers from the disadvtange of
> hard-wiring the user code to the use of such specific cache and
> therefore likely to require user code change if the cache system is
> configured to use something more advanced.� ("likely" unless the
> user code already mark the cache items as Serializable.)
When dealing with an existing system which already uses such a cache
(and I'm certain that many systems do make use of such a varietal of
LRU/MRU cache), plugging in JCS is a lot simplier if existing
interfaces do not have to change. Such a system would find the
excellent and open source JCS implementation more desirable than their
own home grown approach.
> What other cases do you refer to ?
I was under the impression that other concerns had been raised.
Looking back over the archive, I see only restatements of this same
issue:
http://archives.apache.org/eyebrowse/ReadMsg?listName=turbine-jcs-dev@ja
karta.apache.org&msgNo=259