Mailing-List: contact turbine-jcs-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Turbine JCS Users List" <turbine-jcs-user@jakarta.apache.org>
From: "Hanson Char" <hanson_char@yahoo.com>
To: "'Turbine JCS Users List'" <turbine-jcs-user@jakarta.apache.org>
Subject: RE: Why the caching API should use Serializable rather than Object
Date: Sun, 23 May 2004 15:42:05 +1000
Message-ID: <000401c44088$ae8331e0$cd46d9cb@twogig>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <B4F03221EFC8D4118E7D0002A51307F40D344F6D@exchange.ifilm.com>

It's an old reasoning.  Any mutable object put into a cache is a time-bomb.
Not only is it not thread-safe for clients using the cache, they also can
"destroy" the invariants of the map used in the caching system,
inadvertantly by clients who have references to the mutable objects.

The only way to avoid such problem is to defensively make copies of objects
mutable (ie non-string, non-integer, etc) before saving to and/or retrieving
from the cache.

The Cloneable interface is a failure (again according to Effective Java by
Joshua Bloch) so it's out of consideration.  To my knowledge, the
Serializable interface is left as the only means to allow the caching system
to ever possibly make such defensive copies.  The Serializable interface
certainly comes with it's own cost and cannot be taken light-heartedly, but
the alternative is a violation of Item 24.

Hanson

-----Original Message-----
From: Travis Savo [mailto:tsavo@IFILM.com]
Sent: Sunday, 23 May 2004 8:16 AM
To: 'Turbine JCS Users List'
Subject: RE: Why the caching API should use Serializable rather than
Object


While I absolutely agree with the principle of defensive coding, the use of
protected and private keywords to denote fields in a class which are not
meant to be touched by clients of the class, the invariant pattern in
general (constructor only with no public setter being the most common way to
implement this... java.lang.String is an excellent example), and the
potential for Bad Things(tm) to happen when the invariant pattern is not
observed religiously when dealing with Sets and Maps, I'm not following the
Object vs. Serializable argument being made here.  A Serializable object is
not inherently an invariant. Serializable's only contract is that ALL
fields, public or otherwise, must be either primitives, Serializable
themselves, or 'transient'.  The original reasoning (and this is merely
conjecture on my part so don't take this as law) for using Serializable as
the interface was that any cache which did anything more than store
references in memory would use this interface, and the contract supplied by
it to ensure that an object could be captured in a deconstructable form for
the purpose of moving 'outside the VM' with it... whatever that form may
take (Byte stream, XML document, etc.)  The reasoning for removing this
dependency was that all caches don't need it (specifically memory based
caches) and that those who did need it would enforce this dependency
themselves.  The need for the invariant still exists, but to the best of my
understanding, the Serializable interface NEVER provided that contract.  I'm
sure I'm missing something (obvious or otherwise), so could you please
elaborate on your reasoning?  Thank you!  -Travis Savo <tsavo@ifilm.com>

-----Original Message----- From: Hanson Char [mailto:hanson_char@yahoo.com]
Sent: Saturday, May 22, 2004 5:39 AM To: 'Turbine JCS Users List' Subject:
Why the caching API should use Serializable rather than Object   Quoted from
Item 24 of Effective Java by Joshua Bloch:  "You must program defensively
with the assumption that clients of your class will do their best to destroy
its invariants."  "...if you are considering using a client-provided object
reference as an element in an internal Set instance or as a key in an
internal Map instance, you should be aware that the invariants of the set or
map would be destroyed if the object were modified after it were inserted."
This principle/rule is generally violated in JCS for the use of Object in
the method signature.
anson   --------------------------------------------------------------------
- To unsubscribe, e-mail: turbine-jcs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail:
urbine-jcs-user-help@jakarta.apache.org  -----------------------------------
---------------------------------- To unsubscribe, e-mail:
turbine-jcs-user-unsubscribe@jakarta.apache.org For additional commands,
e-mail: turbine-jcs-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-user-help@jakarta.apache.org