Oh.... and when something implements Serializable, the serial form must be either documented in the Javadocs or the Javadocs must be quite clear and say that the serial form might change in future releases. Either way, don't forget serialVersionUID and to update it if the serial form ever changes.
Sam Halliday wrote: > > Absolutely remove from the interfaces... but leave on implementations :-) > That way all future implementations aren't forced to be compatible to > their first release. > > Hopefully we'll address transport of instances in 2.1 with Matrix Market > IO, which should also encourage more efficient compression. > > > Luc Maisonobe wrote: >> >> 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.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. >>>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> >> > > -- View this message in context: http://www.nabble.com/commons-math%2C-matrix-toolkits-java-and-consolidation-tp23537813p23656955.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
