Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <40B0F585.5000102@latte.harvard.edu>
Date: Sun, 23 May 2004 15:03:33 -0400
From: "Mark R. Diggory" <mdiggory@latte.harvard.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7a) Gecko/20040219
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [math][proposal] Drop serialization from selected classes
References: <40B0D0E5.4040900@steitz.com> <40B0DC91.4070002@latte.harvard.edu>
 <40B0E031.9030302@steitz.com> <40B0EA97.4010200@latte.harvard.edu>
 <002001c440f5$bad98800$ab949a51@oemcomputer>
In-Reply-To: <002001c440f5$bad98800$ab949a51@oemcomputer>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Stephen Colebourne wrote:

>>The Math API maintains no "transient" fields. However, we do have
>>"private static" fields in many classes and it would eventually be wise
>>to verify these are or are not properly handled during the serialization
>>process. I've worked hard on the statistic packages and feel confident
>>that I've address the state of its static fields appropriately.
> 
> To be clear, static fields are not stored in the serialized data, or altered
> when an instance is created from serialized data.
> 

Yes, so what needs review is if an when a field is static, is it altered 
at any time in any way. I know this doesn't happen at least in the stat 
package. I'm not 100% sure concerning elsewhere, an code review on my 
part should be relatively easy.


> 
>>Serialization Id's are only necessary if you are going to have a
>>concern with serializing across versions of the math library and want to
>>be able to match similar classes in different versions. This is not
>>something that I see happening allot, usually when I am serializing, I
>>am deserializing using the same version of the library because my
>>application is installed on all machines I'm running the simulation on.
> 
> As a reviewer, I would be content, not happy, if there was a clear statement
> that the serialized format may change between versions of the library.
> However, using an assigned serialVersionUID will greatly reduce the chance
> of breakages and let the JDKs design really work.
> 

This is very true and would probably be the same amount of work as the 
proposed removal of the Serialization Interfaces.
> 
>>The benefit of letting the JVM generate the serialVersionUID's is that
>>you don't need to update them every time you change something in your
>>classes.
> 
> AFAIN this is incorrect. Although the serialVersionUID is generated based on
> the methods and fields of the class it is in fact just a number. Simply
> declaring every serializableVersionUID with the id of 1 would also work.
> 

Yes, I probably misspoke or wasn't very clear. It is sufficient to have 
simply the Serialization interface to facilitate serialization. I agree 
it is advantageous to maintain serialversionUID's to take full advantage 
of the JVM. Though, for bare bones serialization within the same API 
version and JVM, the autogeneration of serialversionUID's is available 
and sufficient.

> The key point is that you never change the serialVersionUID once you have
> assigned it. The default tool simply provides a suitable number that is
> unlikely to be duplicated in another class.
> 

Very true, Serialization UID's provide a means to identify appropriate 
classes to deserialize to when attempting to deserialize across versions 
of the API/JVM. If you anticipate requiring the (de)serialization of 
checkpoints across both versions of the API and versions of the JVM, 
then yes it is wise to maintain serialversionUID's.

> Thus, I would still encourage [math] to provide a serialVersionUID in every
> serializable class.
> 
> Stephen
> 

I'll be glad to go through the API and generate these where they are absent.

-Mark

-- 
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org