On 12 March 2012 16:25, James Carman <jcar...@carmanconsulting.com> wrote: > We could say we support short-term storage (or transmission-only) only when > it comes to serialization. That would help eliminate some of the burden
Perhaps, but why take on any burden without a good use case? Any form of serialisation adds extra testing and maintenance overhead. > On Mar 12, 2012 11:23 AM, "sebb" <seb...@gmail.com> wrote: > >> On 12 March 2012 09:02, Jörg Schaible <joerg.schai...@scalaris.com> wrote: >> > Emmanuel Bourg wrote: >> > >> >> Le 12/03/2012 00:16, Benedikt Ritter a écrit : >> >> >> >>> I just saw that CSVFormat implements Serializable, but neither does it >> >>> provide a no-arg constructor nor any of the special serialization >> >>> methods (and it has no custom serialUID). Is this the way it is >> >>> supposed to be? >> >> >> >> I wrote a test and it seems the serialization works fine. I think the >> >> no-arg constructor is only required if the class is expected to be >> >> subclassed, which isn't the case for CSVFormat. The UID is generated >> >> automatically by the compiler. >> > >> > Which silently imply that all compilers from all vendors generate the >> same >> > UUID in all versions ... which is not the case. >> >> Indeed, but merely adding a UUID is not enough. >> The UUID needs to be maintained - when the class is changed, it may >> need to be changed too. >> If backwards compatibility is required, extra care needs to be taken >> to make this work; if compatibility is not desired, the UUID needs to >> be changed when appropriate to prevent incompatible versions causing >> runtime failures. >> >> Adding Serializable effectively puts (some) implementation details >> into the public API, and increases the maintenance burden. >> >> So unless there is a strong use case which cannot be solved in other >> ways it's best to avoid using serialisation. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
