commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [csv] Serializable on CSVFormat
Date Mon, 12 Mar 2012 16:30:27 GMT
On 12 March 2012 16:25, James Carman <jcarman@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" <sebbaz@gmail.com> wrote:
>
>> On 12 March 2012 09:02, Jörg Schaible <Joerg.Schaible@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message