Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4A157705.3010002@free.fr>
Date: Thu, 21 May 2009 17:45:09 +0200
From: Luc Maisonobe <Luc.Maisonobe@free.fr>
User-Agent: Thunderbird 2.0.0.21 (X11/20090409)
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
References: <23537813.post@talk.nabble.com> <4A0C6C54.9070008@free.fr>
 <4A0E157E.1020201@gmail.com>
 <c7d45fc70905151841m3277d4adw8a4dd4f4b11c752e@mail.gmail.com>
 <4A0E22B2.9030102@gmail.com> <4A0E7B48.3030905@free.fr>
 <23574535.post@talk.nabble.com> <4A0EDF32.7010703@free.fr>
 <23575419.post@talk.nabble.com> <4A0EEC7C.3010507@free.fr>
 <23575674.post@talk.nabble.com> <23575831.post@talk.nabble.com>
 <4A0EF740.4000705@free.fr>
 <c7d45fc70905161301k4f6d32bu4a13ad1a885b8006@mail.gmail.com>
 <00ba01c9d678$e2af7920$b29633ad@oemcomputer> <23595640.post@talk.nabble.com>
 <000701c9d82f$f67d7750$f17ae560@oemcomputer> <23611886.post@talk.nabble.com>
 <4A144671.5020406@gmail.com> <00f201c9d9b7$076b39c0$f17ae560@oemcomputer>
 <23650705.post@talk.nabble.com> <4A1546B0.3000503@free.fr>
 <25aac9fc0905210547i7e4abe27ob4bc6766bc8ba220@mail.gmail.com>
 <4A15512B.10104@free.fr>
 <25aac9fc0905210709r5f8d1f5av1a984e76956a15a7@mail.gmail.com>
 <23655263.post@talk.nabble.com>
In-Reply-To: <23655263.post@talk.nabble.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Sam Halliday a �crit :
> Luc... couldn't agree more regarding Serializable. Adding the Serializable
> interface instantly means you not only have to be API compatible with future
> releases but also binary Serializable compatible. This is what stung MTJ...
> it means you can't swap internal details of fields.
> 
> I strongly recommend everybody read the Bloch chapters on Serialisation
> before ever implementing that interface.

OK. What do you suggest now ? Completely remove Serializable (which
would really bother me as I do use it) or remove it from interfaces and
add it appropriately to some implementation classes ?

Luc

> 
> 
> sebb-2-2 wrote:
>> On 21/05/2009, Luc Maisonobe <Luc.Maisonobe@free.fr> wrote:
>> Nevertheless, adding serialization needs to be considered carefully,
>> as pointed out here:
>>
>> http://www.javapractices.com/topic/TopicAction.do?Id=45
>>
>> Furthermore, readObject() cannot be used with final fields. Bloch
>> (Effective Java) suggests using readResolve() instead, but even this
>> has limitations.
>>
>> As the book points out, merely making a class Serializable is
>> equivalent to adding a public constructor which sets all the
>> non-transient fields without perfoming any validation.
>>
>> If there are any constraints on the fields, these have to be addressed
>> in readObject() and/or readResolve() methods.
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org