commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
Date Thu, 21 May 2009 15:45:09 GMT
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


Mime
View raw message