cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
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/fo m 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 20:48:52 GMT
On Jue, 13 de Enero de 2005, 14:32, Niclas Hedhman dijo:
> 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.
> 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.
> 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.

Thanks for the better explanation. :-D

As I told before, I am planning to add new changes on the serialization
side including writing read/write Object methods. I believe this could
make it a little bit more stable as is part of write health code.

Best Regards,

Antonio Gallardo

View raw message