Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of heinz.drews@gmail.com designates
 66.249.92.175 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=sJaG8LxZy41QHDtmNQJVYHBqKdvlPMf7skTc9JX1HevNVmkZyZ3O9Gui/BhBZAX+j77WJvueX7umu3zMna5ZTgtgQ9tc+/N9sGlsZW4JX/K45PsaWXwIgMKMcDJ/X1Ux+GpXJMrzZObkyfad/GXUMAnATUYt+EE57sPwacKH4Qc=
Message-ID: <4369f0ce0608310834r4c5969bev3d17d39309c56874@mail.gmail.com>
Date: Thu, 31 Aug 2006 17:34:28 +0200
From: "Heinz Drews" <heinz.drews@gmail.com>
To: dev@geronimo.apache.org
Subject: Re: Standard for serialVersionUID
In-Reply-To: <3D8E84095C6A524A985B787423094E4039F2F1@mssmsx411>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <3D8E84095C6A524A985B787423094E4039F2F1@mssmsx411>

Hello Vasily,

in several projects we had made serialVersionUID mandatory for all
serializables.
And because it's just an id a lot of opinions are coming up in
discussions how to specify it.

Just as clarification, in the approach with the version number it was
not changed with each modification.  Only if a change was causing an
impact to the serialized version.
Rationale was that in case of a mismatch the message would be easier
to interpret then the traditional values.

But I guess the traditional approach would be the preferred.

Regards,
Heinz

On 8/31/06, Zakharov, Vasily M <vasily.m.zakharov@intel.com> wrote:
> Heinz,
>
> Adding serialVersionUIDs to Serializable classes is sure a great idea!
> It's strongly recommended by Sun, and all the way helps when dealing
> with serialization in large projects.
>
> It's not in fact important what particular value you specify for
> serialVersionUID field, the only thing important is you change the
> serialVersionUID for a class when its serialized form changes, and ONLY
> if its serialized form changes. From this perspective, using class
> version number is not a good idea, as a class may be modified (and thus
> version number changed), but a serialized form may stay the same, and
> changing serialVersionUID would introduce an unnecessary serialization
> incompatibility.
>
> The traditional way is to use 'serialver' program from Sun's JDK. If
> this way is for some reason uncomfortable for you, you may use some
> other way to calculate serialVersionUIDs, like Eclipse built-in feature
> or the like. The particular value is not important, only changes to it
> are.
>
> Note however, that small values like 1 or 2 are traditionally used as
> serialVersionUIDs for synthetic and other system classes, like Enums and
> RMI Stubs, that are serialized in a special way. So using such values in
> "normal" classes may confuse the future readers of the code and make
> them wonder if that particular class is serialized in a special way. So
> I'm suggesting using traditional (20-digit or so) values for
> serialVersionUIDs.
>
> Thank you!
>
> Vasily Zakharov
> Intel Middleware Products Division
>
>
> -----Original Message-----
> From: Heinz Drews [mailto:heinz.drews@gmail.com]
> Sent: Thursday, August 31, 2006 9:46 AM
> To: geronimo-dev
> Subject: Standard for serialVersionUID
>
> As I have mentioned in another message I have accidently used class
> files in modules created by Eclipse embeded compiler.  This calculates
> serialVersionUID different way then javac.
>
> I think that adding serialVersionUID to all serializable class would
> address the situation best.
> There are quite a number of class without the uid.  I would volunteer
> to add them but which standard should be used?
>
> Eclipse provides the option set it to 1 or  to calculate the uid. But
> the calculation is different to the one doen by javac.
>
> In other projects I have found the convention to use version number to
> support detection of incompatible modifications.  The version number a
> much nicer to read in the message reporting mismatches than the
> generated ones.
>
> Least impact would be to calculate the value with the serialver tool.
> This avoids the need for redeploying.
>
> Which standard should be chosen?
>
> --Heinz
>