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