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
