cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: svn commit: r124693 - in cocoon/branches/BRANCH_2_1_X/src: blocks/authentication-fw/java/org/apache/cocoon/webapps/authentication/configuration blocks/axis/java/org/apache/cocoon/components/axis/providers blocks/forms/java/org/apache/cocoon/forms/event blocks/forms/java/org/apache/cocoon/forms/flow/javascript blocks/forms/java/org/apache/cocoon/forms/flow/javascript/v2 blocks/forms/java/org/apache/cocoon/forms/formmodel blocks/paranoid/java/org/apache/cocoon/servlet blocks/scratchpad/java/org/apache/cocoon/components/flow/javascript/fom blocks/scratchpad/java/org/apache/cocoon/generation blocks/web3/java/org/apache/cocoon/components/web3/impl java/org/apache/cocoon/components/flow/javascript/fom java/org/apache/cocoon/servlet
Date Thu, 13 Jan 2005 13:37:33 GMT
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.


View raw message