On second thought, it may be more interesting if we can provide our own subclass/implementation of ObjectOutputStream/ObjectInputStream such that they will serialize/deserialize any objects REGARDLESS of whether they have been marked with the Serailizable interface, with other behavior being exactly the same as the original i/o stream classes.
The biggest benefit of such approach is we will by definition NEVER get a NotSerializableException, and the user code never need to care about marking objects as Serializable. We baiscally take over the decision and automate it as necessary in the caching system. Then once the caching system is wired to use these special object i/o streams, we can "magically" serialize/deserialize objects if so need to regardless, and therefore can maintain the existing interface signatures of using the Object parameter type for cache item's key/value. Any idea why the above suggestion may fail, or any potential pitfall ? (Seems like a perfect solution to me.) Hanson -----Original Message----- From: Hanson Char To: 'Stephen Haberman '; ''Turbine JCS Developers List' ' Sent: 7/21/2002 9:16 AM Subject: RE: [patch] simple patches I'd like to point out the suggestion to the parameter type change is to HELP solve the serilization problem but does NOT eliminate it. As documented in java.io.Serializable, "When traversing an graph, an object may be encountered that does not support the Serializable interface. In this case the NotSerializableException will be thrown and will identify the class of the non-serializable object." So basically the user is made aware and enforced by the compiler that the cache key/value must be of type Serializable, and in the case of some member object being not, NotSerializableException will still be thrown during runtime. Such situation is not avoidable in any case (unless extraordinary effort is made.) Changing the parameter type to Serializable, however, makes it explicit in the interface about what the cache system IN GENERAL expects, and in the worst case will automaticaly signal a meaningful exception (NotSerializableException) via the JRE WITHOUT us doing anything. Hanson -----Original Message----- From: Stephen Haberman To: 'Turbine JCS Developers List' Sent: 7/21/2002 1:44 AM Subject: RE: [patch] simple patches I can't comment on the technical details of using Serializable vs. Object, e.g. the in-memory only argument, but as a newbie user, I definitely like the compile time error better than a runtime error I have to track down and decipher. And I also want to have a smooth transition from a simple, in-memory only cache, to full fledged, save-to-disk stuff and having to suddenly implement Serializable is a lot less elegant than just changing the property files (which, btw, is very sexy; JCS looks like a great system). Well, okay, the one thing I have against the argument that Object should be kept as the parameter type is in both CacheAccess put methods, you specifically cast the key and value variables to Serializable before handing them off any where, as both the ICacheElement and CacheElement implement Serializable. So while hiding the internals from the user is great and all, the implementation would have to change (drastically, I would think) for ICacheElement and CacheElement to no longer extend Serializable - Stephen > -----Original Message----- > From: Hanson Char [mailto:[EMAIL PROTECTED]] > Sent: Saturday, July 20, 2002 11:53 PM > To: 'James Taylor '; 'Turbine JCS Developers List ' > Subject: RE: [patch] simple patches > > The existing use of Object as the key/value parameter type for the cache > interface menas the only type of cache implementation that can be configured > to use underneath must be nothing other than the simplest kind of > memory-only cache you described, UNLESS the user of the cache interface > makes the extra effort to mark his cache items passed to the interface as > Serializable. Even then, such user will have no way to verify if he has > done it correctly or not until during runtime. > > If such user so decided that he wants to extend his use of the cache in any > way, (such as adding the use of an auxiliary disk cache, or the use of > remote cache, or make the content of the cache items immutable, etc.), he is > likely to get a runtime exception (and therefore likely to have to change > his code) unless he made the cache item Serializable in the first place. > > On the other hand, requiring all key/value parameter type for the cache > interface to be Serializable helps solve all the above problems via the > compiler, AND one can still use the simplest kind of memory-only cache with > zero runtime penalty. > > Also, "secondary storage" can mean something faster than the disk. For > example, conceivably one can provide a cache implementation via JNI to use > the portable library for shared memory used in Apache/EAPI (mm-1.1.x.tar.gz > from http://www.engelschall.com/sw/mm/). Again this is only possible if the > cache items are Serializable. > > In short, changing the parameter type of the cache interface from object to > Serializable provides the benefit of releasing the user code from being > hard-wired to one specific (and simplest kind of) cache he must configure to > use, at the cost of simply requiring the user of the cache interface to mark > their cache items as Serializable, which the user is likely to do it anyway. > > Hanson > > -----Original Message----- > From: James Taylor > To: Turbine JCS Developers List > Sent: 7/20/2002 10:23 AM > Subject: RE: [patch] simple patches > > On Sat, 2002-07-20 at 08:29, Hanson Char wrote: > > But isn't it true that even in-memory cache will eventually come > across the > > problem of overflow, which therefore requires the ability for the > cache > > items to be serialized and saved in some secondary storage ? > > For some applications, where the serialize to disk speed is more than > the time to create the objects, or the objects are known to be very > transient, the best overflow behavior may be to just drop the least > recently used items. > > > One can agrue the use of techniques such as SoftReference to avoid the > > memory overflow problem, but such implementation is the > exceptional/specific > > case rather than the standard/canonical. > > > > If the above argument is sound, the existence of a standard such as > JCACHE > > should not stop us from trying to change/enhance/improve the standard > > itself. Or, If the standard cannot be changed owing to non-technical > > reasons, I would say we should create our own (better) standard for > goods, > > rather than to bindly/strictly follow it. > > We are not absolutely following JCache anymore, so if we agree that > something like this is the best way to go, we will absolutely change the > API. > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
