[ https://issues.apache.org/jira/browse/MATH-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211328#comment-13211328 ]
Gilles commented on MATH-742: ----------------------------- bq. I am not understanding what problems this could cause - can you give some explicit examples? I don't know what your criteria are for "appropriate serialization code" - can you describe a case where the default serialization code is not appropriate and why it is not appropriate? I guess that the most trivial problem is serializing with some version of the library and deserializing with another where the internal structure has changed in the meantime (e.g. substituting one instance variable with another that would provide the same basic functionality). Please note that the position which I am defending here is not based on "my" criteria for how to handle "Serializable". I'm reporting concerns very well explained in the book "Effective Java" by J. Bloch. Those concerns might be far-fetched and we are totally entitled to ignore them in standalone applications but in the case of a _library_, we should not presume of the innocuousness of anything we put in. bq. As far as I can tell, the writeObject() and readObject() methods in ExceptionContext are unnecessary because they simply do what the default mechanism does anyway (except that it replaces throwing an exception for a non-serializable object with a String that says it is non-serializable). What am I missing? That the exception context is part of the exceptions defined in CM: If a non-"Serializable" object is stored in the context, it must be detected, lest the default serialization generates another exception, the result of which would be that the original exception cannot be propagated remotely. Concerning your last series of points, there are answers at several different levels. * Policy (as a means toward consistency of code design, implementation and maintenance): Cf. previous posts. * Resources: CM's core business is mathematical utilities programmed in clear OO Java code. This alone is already too much for a small team. Adding more administrivia is IMHO unreasonable ATM. * There is no encapsulation breaking: The code uses only "public" accessors in order to extract the objectively meaningful data that are needed to define the concept represented by "PolynomialSplineFunction" (the knots and the set of coefficients of the polynomial functions that are connected at the knots). * In some sense, the default serialization breaks the encapsulation because the object is deserialized without undergoing the constructor's precondition checks; while the "SerializationProxy" actually enforces encapsulation by passing the deserialized to the constructor. > Please make PolynomialSplineFunction Serializable > ------------------------------------------------- > > Key: MATH-742 > URL: https://issues.apache.org/jira/browse/MATH-742 > Project: Commons Math > Issue Type: Improvement > Affects Versions: 2.2 > Reporter: Neil Roeth > Priority: Minor > Attachments: PolynomialSplineFunction.java > > > PolynomialSplineFunction is not Serializable, while the very similar > PolynomialFunction class in the same package is. All that needs to be done is > to add the import: > {{import java.io.Serializable;}} > and change this: > {{public class PolynomialSplineFunction implements > DifferentiableUnivariateRealFunction}} > to this: > {{public class PolynomialSplineFunction implements > DifferentiableUnivariateRealFunction, Serializable}} > I made exactly that modification to a local copy and it serialized > successfully. Before the change, I got serialization errors. > Thanks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira