Cloneable per se is indeed a marker interface just like Serializable. However, according to the JDK API,
"A class implements the Cloneable interface to indicate to the Object.clone() method that it is legal for that method to make a field-for-field copy of instances of that class." And if you check out the Object.clone() API: "The method clone for class Object performs a specific cloning operation. First, if the class of this object does not implement the interface Cloneable, then a CloneNotSupportedException is thrown. Note that all arrays are considered to implement the interface Cloneable. Otherwise, this method creates a new instance of the class of this object and initializes all its fields with exactly the contents of the corresponding fields of this object, as if by assignment; the contents of the fields are not themselves cloned. Thus, this method performs a "shallow copy" of this object, not a "deep copy" operation." The shallow copy is not good enough in general for thread safety. Hence my conclusion of it not being as good as Serializable. These 2 interfaces both have the potential of throwing some kind of runtime exception (not cloneable or not serializable) and therefore they don't really differentiate much from each other based on the runtime exception throwing behavior. Assuming no exception is thrown, however, in general Serializable provides possible deep clone implementation which Cloenable does not. Hence Serialziable is better for thread saftey purposes. Hanson -----Original Message----- From: Heinz Drews [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 28, 2003 7:07 AM To: Turbine JCS Users List Subject: Re: Why a cached object must be Serializable Hanson, First: > Interesting idea but Cloneable won't work as Cloneable only suggests > "shallow copy" (like the Object.clone() behavior) which is insufficient to > provide thread safety if there are composite modifiable parts in the cached > item. Cloneable is a marker interface which indicates that an Object accepts to get clone() invoked. No conclusion about the implementation of clone() can be made. Second: > Serializable is better. What gets you to the idea that serializing/deserializing would provide always a clone of the object? Beside the facts you mentioned yourself that any object can throw NotSerializable which would screwup the cloning in a pretty way nothing can prevent that readResolve() is implemented. And in readResolve() it would be possible to retrieve an object reference from the cache and return it instead of the expensively constructed copy. Third: The reason why I use a cache is to have a managed container for objects which are expensive to construct. But the cache is not the final container because objects can be simply removed from the cache when the cache manager applies the defined strategy. A backup of a cache into an auxiliary storage is an optional way to increase the cache capacity. And a solution which requires careful consideration because it might be faster to construct the object again from the real source then using the generic approach implemented in an aux cache. Fourth: As Les wrote feel free to implement a solution which provides the behavior you so strongly desire. This allows that everybody can use it if wanted. If the cloning would be made the default behavior I would only see two options for my projects: - Looking for a real cache implementation to replace JCS - Removing the @*# from the JCS sources Open source is a wonderful thing. Fifth: Can you please go back to square one and describe your problem instead of discussing an assumed generic solution for a problem only you have? If not then this will be my last comment to the topic. Best regards, Heinz --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
