commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Halliday <sam.halli...@gmail.com>
Subject Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
Date Thu, 21 May 2009 15:31:38 GMT

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.


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.
> 

-- 
View this message in context: http://www.nabble.com/commons-math%2C-matrix-toolkits-java-and-consolidation-tp23537813p23655263.html
Sent from the Commons - Dev mailing list archive at Nabble.com.


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


Mime
View raw message