[
https://issues.apache.org/jira/browse/MATH-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211878#comment-13211878
]
Neil Roeth commented on MATH-742:
---------------------------------
Of course, I'm fine moving the general discussion elsewhere. IIRC, that
suggestion was made earlier in this thread by someone. :-) To answer your
specific questions:
bq. 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.
I meant private fields with no public accessors, and the requirement you state
is precisely the one that would make the class impossible to serialize with the
idiom while it would be possible with the other methods.
bq. Could you give a concrete example where one would need to serialize a RNG
(where it must continue drawing from the same sequence)?
Pretty much any RNG should continue using the same sequence rather than
restarting from a new seed if the sequences are meant to model the same random
element. So, a calculation where you do part of the calculation, do some
processing, then do some calculation might be an example. However, evaluating
whether this particular case needs to be serialized is missing the point. The
point is that there are classes (like this RNG) where the constructor
preconditions that the idiom depends upon are nowhere near sufficient to
guarantee that an identical object can be created. If you prefer, think of
class A with a constructor that takes an argument of class B, then creates from
that an internal instance of class C that is required to completely define the
state of an instance of A. There is no public accessor for C because that
field has no meaning outside of the class itself. The instance of class B used
to construct the instance of A is useless after the object is constructed, so
it is not saved and therefore is not available at serialization/deserialization
time to construct a new instance. The idiom cannot handle that, but the default
serialization or explicit writeObject() and readObject() methods can (as long
as class C is made Serializable).
I would be happy to respond to the other, more general points, but since you
asked to suspend further comments on the general issue and others are probably
tired of the discussion :-), I'll not do so.
> 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
