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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
