Hello.
> >
> > "Serializable" is a lot of work indeed: cf. revision 1245003, where the
> > change was to fix bugs detected by "FindBugs":
> > ---CUT---
> > The field org.apache.commons.math3.random.ISAACRandom.arr is transient but
> > isn't set by deserialization
> > ---CUT---
>
> OK. The consensus seems to be to not make everything serializable.
> Do we set Serializable on a case by case basis (hence solving issue
> MATH-742) ?
How do want to solve it?
IMHO, "PolynomialSplineFunction" the perfect example for not being
"Serializable": It is a function, not a data storage object.
And it already provides the necessary accessors ("getKnots" and
"getPolynomials"[1]) for users to
1. save the state in their own data storage structure,
2. serialize however they want it (cf. Ted's opinion about "Serializable"),
3. reconstruct the object using the normal constructors.
In any scenario like the above, I would *not* have the class
"Serializable".[2]
Best regards,
Gilles
[1] And "PolynomilaFunction" provides "getCoefficients" (should thus not be
"Serializable" either).
[2] On the other hand, there was a compelling scenario for having the CM
"ExceptionContext" serializable.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
