[
https://issues.apache.org/jira/browse/MATH-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211606#comment-13211606
]
Gilles commented on MATH-742:
-----------------------------
According to the general convention, this discussion should be ported to the
"dev" ML, possibly with a subject prefix of "[ALL]" so that we can get opinions
of people who are much more knowledgeable than me on the pros and cons of
supporting serialization.
After I respond to the last points raised here, we could maybe suspend the
comments in this forum...
Adding an "implements Serializable" on a case-by-case basis is not a substitute
for a policy (i.e. defining what would be the ideal state for CM). Personally,
I think that it will not help users in the long-term, because they will know
(because we'll tell them) that they should not rely on a serialization policy
that reads "{{Serializable}} is added for your convenience but is otherwise
unsupported".
I don't understand why the idiom would break down with the addition of a
private field; the only requirement is that a class provides accessors to
everything one needs to reconstruct an identical object.
Could you give a concrete example where one would need to serialize a RNG
(where it must continue drawing from the same sequence)?
There is one subversion which you did not mention (which is the one that
usually comes up when the experts talk about serialization) is the possible
corruption (accidental or intentional) that could happen while the data goes
over the wire. That's what the idiom can thwart.
On the other hand, you enumerate many sources of possible bugs in the
implementation of serialization: That's exactly why I say that _we_ should not
implement it, unless we have people on the team that can commit to support it!
But that would come back to the issue of policy, having a discussion on the
"dev" ML about what should be the serialized form, which classes should be
serializable and which not, how to decide for border-line cases, etc.
That's a moderately ambitious project. IMHO, it is people like you, that would
benefit from it, who should primarily contribute to it, even if just to start
the discussion on the ML to get on the right track.
As I told at the beginning, the issue is not simply to add "implements
Serializable" to "PolynomialSplienFunction", even if the current lack of
consistency in CM would have you believed that it was, for which we apologize.
;-)
> 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
