[
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
