cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <agalla...@agssa.net>
Subject Re: svn commit: r124693 - in cocoon/branches/BRANCH_2_1_X/src: blocks/authentication-fw/java/org/apache/cocoon/webapps/authentication /configurationblocks/axis/java/org/apache/cocoon/components/axis/provi ders blocks/forms/java/org/apache/cocoon/forms/eventblocks/forms/java/org/a pache/cocoon/forms/flow/javascript blocks/forms/java/org/apache/cocoon/forms/flow/javascript/v2blocks/for ms/java/org/apache/cocoon/forms/formmodel blocks/paranoid/java/org/apache/cocoon/servletblocks/scratchpad/java/o rg/apache/cocoon/components/flow/javascript/fom blocks/scratchpad/java/org/apache/cocoon/generationblocks/web3/java/or g/apache/cocoon/components/web3/impl java/org/apache/cocoon/components/flow/javascript/fomjava/org/apache/c ocoon/servlet
Date Thu, 13 Jan 2005 23:09:50 GMT
On Jue, 13 de Enero de 2005, 7:37, Vadim Gritsenko dijo:
> Niclas Hedhman wrote:
>> On Wednesday 12 January 2005 06:14, Vadim Gritsenko wrote:
>>
>>>Even though above classes are Serializable, none of those classes have
>>>witeObject / readObject methods. Next change to any of those classess
>>> will
>>>cause exceptions during serialization, if somebody to try it.
>>>serialVersionUID should be removed.
>>
>> This is not a true statement.
>
> Ok, "next incompatible change" - that's what I meant.
>
>
>> By having serialVersionUID explicitly declared, instead of the
>> automatically
>> generated number from the class' signature, means that any compatible
>> change
>> can be made without serialization exceptions.
>>
>> For instance,
>>
>> if you add methods  -->
>>   serialVersionUID not present == exception
>>   serialVersionUID present == no problems.
>>
>> if you add fields -->
>>   serialVersionUID not present == exception
>>   serialVersionUID present == fields with no values in the stream are
>> not
>> assigned, values in the stream for which there are no fields are
>> ignored.
>>
>>
>> Generally speaking, if you add "implements Serializable" to a class, you
>> should also add the serialVersionUID, and == 1 is good enough.
>
> I am of opposite opinion. If no effort is made to preserve compatibility,
> no
> serialVersionUID should present. Moreover, serialVersionUID should be
> added only
> when making incompatible change and doing an effort to preserve
> compatibility.
>
>
>> If serialization compatibility is essential between versions of the
>> application, then it is strongly recommended that readObject and
>> writeObject
>> methods are also added, since you have better control of how to deal
>> with
>> differences.
>
> Here, I'm in agreement.

Yes. As told before, I have plans to do that too. ;-)

Best Regards,

Antonio Gallardo

Mime
View raw message