as this. I do not think that it is something that should limit us from releasing. It is a secondary characteristic that does not impact currently existing performance outside of serialization. I also think removing it sets us back in terms of its development. If it is a sensitive subject, we can suggest via disclaimer that it is under development in various areas of the API at this time and usage is not fully tested.
If your looking for examples where it is used. I'm currently using
them with Simulations using RePast and Mason. Mason allows checkpointing
the simulations to serialized files and then deserializing and restarting them. This allows for both "distributed simulation" and for persistence of state. Being able to checkpoint the stat classes is critical in my applications.
I never fully addressed his email issues. So I will start to do so now:
Stephen Colebourne wrote:
2) Wherever there is implements Serializable you should have a serialVersionUID static field. And are you confident that the implementations are well enough established to allow for serialization?
I use it now on a regular basis with the stat package.
Stephen Colebourne wrote:
What about transient fields? Serialization is definitely not about adding the implements clause to everything.
From Sun Tutorial:
Several techniques are available to protect sensitive data in classes. The easiest is to mark fields that contain sensitive data as
private transient. transient and static fields are not serialized or
deserialized. Marking the field will prevent the state from
appearing in the stream and from being restored during
deserialization. Since writing and reading (of private fields) cannot
be superseded outside of the class, the class's transient fields are
safe.
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.
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.
The cost of automated calculation of serialVersionUID's is small, "one time" at JVM startup and cached.
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. I have generated for many of the stat classes I've been working on. If it really arose that this was an issue (issue brought up by user) I would gladly take on the responsibility and address it by generating and maintaining serialversionUID's for the rest of the classes in the project.
Myths about Serialization performance: http://www.javaworld.com/javaworld/javaqa/2003-06/02-qa-0627-mythser.html
An excellent article with performance timings and examples of using serialization to accomplish cloning: http://www.javaworld.com/javaworld/javaqa/2003-01/02-qa-0124-clone.html
Sun Tutorial on Serialization: http://java.sun.com/docs/books/tutorial/essential/io/providing.html
-Mark
Phil Steitz wrote:
Mark R. Diggory wrote:
I'm not sure why your want to do this? We've already put a great deal of effort into assuring its possible and consistent.
I would like to see as much serialization maintained as possible. Being able to serialize/deserialized these objects is a powerful feature. I've worked hard to show that this serialization is functional and error free with the tests that I have written (at least in the statistics package).
Cf. Stephen's remarks on serialization in the API review. Unless there is a compelling reason for these classes to be serializable, I would prefer not to force ourselves (and anyone subclassing these things) to maintain support and worry about serialization compatability. Can you explain why these classes (many of which have
no state) *should* be serializable?
-Mark
Phil Steitz wrote:
I would like to modify the following classes to make them no longer implement Serializable. Any objections?
AbstractDescriptiveStatistics BisectionSolver BrentSolver ChiSquareTestImpl DefaultTransformer DescriptiveStatistics DescriptiveStatisticsImpl DistributionFactoryImpl Erf Gamma NewtonSolver SecantSolver SplineInterpolator SummaryStatisticsImpl TTestImpl TransformerMap UnivariateRealSolverFactoryImpl UnivariateRealSolverImpl ValueServer
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- 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]
