1.) Its ok to remove Serialization from Factories which are not instantiated.
2.) Its ok to remove Serialization from Abstract classes.
3.) StaticUtils don't benefit from serialization, I didn't see any with it present within them. If you see any, feel free to remove the Serialization Interface from them.
I would very much prefer to see Serialization interfaces maintained on all non-Abstract implementation classes so that the API can be used within applications which take advantage of Serialization.
a.) Abstract Classes in which Serialization interface can be removed without impact to overall serialization of API:
o.a.c.m.analysis.UnivariateRealSolverImpl o.a.c.m.stat.univariate.SummaryStatistics o.a.c.m.stat.univariate.DescriptiveStatistics
b.) Classes I would like to maintain Serialization on (and for which its pretty much zero effort).
o.a.c.m.analysis. BisectionSolver BrentSolver NewtonSolver PolynomialFunction PolynomialSplineFunction SecantSolver SplineInterpolator UnivariateRealSolverFactoryImpl --> Instantiable Factory
o.a.c.m.complex. Complex ComplexFormat
o.a.c.m.distribution. BinomialDistributionImpl ChiSquaredDistributionImpl DistributionFactoryImpl --> Instantiable Factory ExponentialDistributionImpl FDistributionImpl GammaDistributionImpl HypergeometricDistributionImpl NormalDistributionImpl TDistributionImpl
o.a.c.m.linear RealMatrixImpl
o.a.c.m.random EmpiricalDistributionImpl (Pluse inner classes) RandomDataImpl
o.a.c.m.stat Frequency
o.a.c.m.stat.inference ChiSquareTestImpl TTestImpl
o.a.c.m.stat.multivariate BivariateRegression
o.a.c.m.stat.univariate DescriptiveStatisticsImpl StatisticalSummaryValues SummaryStatisticsImpl
o.a.c.m.stat.univariate.xxx (All classes)
o.a.c.m.util ContinuedFraction ContractableDoubleArray DefaultTransformer ExpandableDoubleArray FixedDoubleArray TransformerMap
c.) With very little effort I can make the following Serializable such that the Replayable Data Streams can be recovered and continued on from given the presence of the Datasource is available.
o.a.c.m.random ValueServer
So, to review Phil's list:
AbstractDescriptiveStatistics
+1
BisectionSolver BrentSolver ChiSquareTestImpl DefaultTransformer
-1
DescriptiveStatistics
+1
DescriptiveStatisticsImpl DistributionFactoryImpl Erf Gamma NewtonSolver SecantSolver SplineInterpolator SummaryStatisticsImpl TTestImpl TransformerMap UnivariateRealSolverFactoryImpl
-1
UnivariateRealSolverImpl
+1
ValueServer
-0 (I can make it Serializable if you like)
-Mark
p.s. As a reminder, I've serailversionUID's generated for all these files now.
Mark R. Diggory wrote:
Phil Steitz wrote:
Since implementing Serializable requires that all subclasses also implement serializable and that care be taken to ensure backward serialization compatability, my view is that we should implement Serializable iff there is a reason to do so, not by default for all classes.
This is not true, you only have to implement serializable in your subclass if you want to support serialization, there is no requirement that you are forced to do so because the parent class implements it. It is completely transparent to the user in this reguard.
I am interested in others' views on this. Maybe I am missing something, but I see no value in implementing Serializable for factories, abstract classes, utility classes and such.Yes, I'll agree for abstracts, its not really neccessary, it was more a practice on my part to confirm that they were truly serializable. I also agree its probibly not very important for factories, but its a no-brainer, effects very little in terms of source code and performance and is a very simple thing toi maintain. Arguing that this creates all kinds of headaches is really a "Red Herring". I spent an hour on it this afternoon and can confidently state that our API can easily support it without headaches to anyone. Removing it only steps on peoples toes in the long run.
-1 on removing Serialization Interfaces.
Mark
Phil
-----Original Message----- From: Mark R. Diggory [mailto:[EMAIL PROTECTED] Sent: Mon 5/24/2004 12:31 PM To: Jakarta Commons Developers List Cc: Subject: Re: [math][proposal] Drop serialization from selected classes
Just to give an update, I generated serialversionUID's for all the
current Serializable classes in the src/java directory for which they
were absent. I'm just waiting on our clarifying the decision prior
committing everything. I am currently working on a serialization
solution for the ValueServer/EmpiricalDistribution classes.
-Mark
------------------------------------------------------------------------
--------------------------------------------------------------------- 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]
