Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <34785.10.0.0.5.1105763563.squirrel@www.agssa.net>
In-Reply-To: <41E84ED4.5090603@apache.org>
References: <20050109003528.55029.qmail@minotaur.apache.org>   
    <41E530AB.6040504@reverycodes.com>
    <36839.10.0.0.5.1105560123.squirrel@www.agssa.net>
    <41E59299.6050908@reverycodes.com> <41E84ED4.5090603@apache.org>
Date: Fri, 14 Jan 2005 22:32:43 -0600 (CST)
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
From: "Antonio Gallardo" <agallardo@agssa.net>
To: dev@cocoon.apache.org
User-Agent: SquirrelMail/1.4.3a-6.FC2
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal

On Vie, 14 de Enero de 2005, 16:59, Sylvain Wallez dijo:
> Vadim Gritsenko wrote:
>
>> Antonio Gallardo wrote:
>>
>>> Please give me a little time to fix all the serialization changes. I am
>>> currently using the BRANCH head in development this version and I am
>>> checking if everything is working good.
>>>
>>> Anyway this could not harm. It is just a line on each class and we can
>>> remove them if not needed before releasing.
>>
>>
>> No problem, take your time. Just out of curiosity, what is your
>> scenario which requires serialization?
>
> Yes, please explain, Antonio.
>
> Also, and we discussed this already not long ago [1], serial uid is
> useful for long-lived serialized objects where there is a chance that
> the class changes between serialization and deserialization. What in
> Cocoon justifies this?

Shared remote cache. In some cases, they can use diferent java versions
across machines and the troubles can be raisen.

> Furthermore, Niclas' explanation that having a serialVersionUID leads to
> newly added fields to have no value seems particularily dangerous to me
> if we don't take special care about this as it can lead to weird errors.

Nope. Because as you explained in your mail, we are not persisting for too
long time. We will not take an "obscure failure" error. The weird errors
are on the code without serialversionUID, because if you already have a
Object cache cache and add a method to a serialiable class class there
start the problems.

> So I am -1 on adding serialVersionUIDs to Cocoon classes unless there is
> a good reason for this.

First, I am just trying to close posible "collateral damages". I am just
adding the points over the "i"es here.

If we have made the decisions to serialize some classes, we need to finish
the work to avoid potential problems. And this is what I am doing now,
just trying to close this doors by assuring that the serialization is done
as is recommended by people that has more years working in java than me.

What I understood is:

If the class implements the Serializable interface, but does not define a
serialVersionUID field then a change as simple as adding a reference to a
.class object will add synthetic fields to the class, which will
unfortunately change the implicit serialVersionUID (e.g., adding a
reference to String.class will generate a static field
class$java$lang$String). Also, different source code to bytecode compilers
may use different naming conventions for synthetic variables generated for
references to class objects or inner classes. We need toconsider adding an
explicit serialVersionUID to ensure interoperability of Serializable
across versions.

Then reading from Effective Java from Joshua Bloch pag 214, 2nd paragraph:

<snip>
A simple example of the constraints on evolution that accompany
serializability concerns stream unique identifiers, more commonly known as
serial version UIDs. Every serializable class has a unique identification
number associated with it.
</snip>

That means that no matter we do we already have one there!

<snip>
If you don't specify the identify the identification number explicitly by
declaring a private static final long field name called serialVersionUID,
the system automatically generates it by applying a complex deterministic
procedure to class. The automatically generated value is affected by the
class's name, the names of the interfaces it implements, and all of its
public and protected members. If you change any of this things in any way,
for example, by adding a trivial convenience method, the automatically
generated serial version UID changes. If you fail to declare an explicit
serial version UID, compatibility is broken.
</snip>

I am also planning to add Read/Write Object methods on some of this classes.

Best Regards,

Antonio Gallardo