Should not have been on the list, not currently Serializable and as an abstract factory, makes no sense to serialize.These are all used either in stats or tests of stats.
>>> AbstractDescriptiveStatistics
Also a factory, why serialize?>>> DefaultTransformer >>> DescriptiveStatistics
>>> DescriptiveStatisticsImpl >>> SummaryStatisticsImpl >>> TransformerMap
But, like Stephen pointed out, I'd recommend adding serialversionUID's over removing Serialization Interfaces across the entire math package.
I've written simplified serialization/deserialization test support into the TestUtils. As such, its very easy to write tests that simply call this method, then test if all the values are still correct in the Object returned.
http://jakarta.apache.org/commons/math/xref-test/org/apache/commons/math/TestUtils.html#71
The point is not so much just testing, but also the backward compatability issues and extra burden when extending. If you feel that the classes above must implement Serializable, then yes, please generate and add the serialization IDs where they are missing. Can I assume that there are no objections to removing serialization from the classes below? If so, please provide a reason that the class should implenment Serializable.
BisectionSolver BrentSolver ChiSquareTestImpl DistributionFactoryImpl Erf Gamma NewtonSolver SecantSolver SplineInterpolator TTestImpl TransformerMap UnivariateRealSolverFactoryImpl UnivariateRealSolverImpl ValueServer
Phil
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
