On Tue, 2002-07-23 at 04:41, Hanson Char wrote: > 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.
JCS is still pre-1.0 so there is no reason to preserve the Object interface for backwards compatibility. All current usage of the cache requires Serializable objects. > > 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. You seem to have this backward. If I configure the cache to require Serializable classes and I have classes that cannot be Serialized (or would take more effort than just slapping "implements Serializable" on the source). Then I have made an error in configuration, I'm not going to rewrite the application to support the mis-configuration. > > 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. The point is to allow for future improvement to support non-Serializable objects. Even though it is the most trivial configuration of the cache, it is the configuration that will be used when caching non-Serializable objects. > > 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. Why do you say preserving the ability to cache non-Serializable objects is a "lack of foresight"? It is not trivial to an application that has non-Serializable objects that involve expensive operations that could benefit from caching. john mcnally -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
