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.maison...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
