[
https://issues.apache.org/jira/browse/MATH-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211388#comment-13211388
]
Neil Roeth commented on MATH-742:
---------------------------------
Responding to Luc:
bq. I think we can simply say this is not supported. Serialization should not
be used for long time storage, and even if it can be used for distributed
computation with different versions between client and server, we can simply
say we don't support it.
Completely reasonable.
bq. +1 for the concerns of a library, but there are many cases when a simple
"implements Serializable" is sufficient and does not imply too much work.
Yes, agreed. I think this is one of them.
Responding to Gilles:
bq. 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).
Well, yes, but add a private field critical to the state of PolynomialFunction
and the idiom breaks down. There would be no breakdown if the class itself
were responsible for ensuring that readObject() and writeObject() did the right
thing.
Here's an example: Suppose you have a random number generator class RngGilles
that has a constructor that takes a single long integer as an argument. The
constructor precondition returns true for any value of the long integer. With
that long integer, it initializes a private table of several hundred long
integers and a private marker of its current position in the table. When
RngGilles.nextRandom() is called, it calculates the value to be returned from
the table and its current place in the table , then updates the table and its
current place, then returns the value. It does this a billion times, then
needs to be serialized and deserialized in order to continue to use that same
random number sequence in another process. The idiom would fail in that case,
while the default writeObject() and readObject() would succeed.
bq. 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.
I understand what you are saying, but the concept of serialization is that when
you are done deserializing, you have an object that represents the exact same
state as the object that was serialized, so since it already satisfied any
constructor preconditions when it was first created, there is no need to check
them again. It is, of course, possible to subvert this for some particular
class, e.g., through poorly written explicit writeObject() and readObject()
methods, or by failing to mark some fields transient and making methods that
use the transient field handle that, but I'd call that a bug in that particular
object's serialization implementation, not a general failure of serialization
that needs to be handled outside the class by serialization wrappers. ISTM
that the idiom basically boils down to deconstructing objects to their
primitive fields and then reconstructing them from those primitives, completely
bypassing the whole Serialization mechanism except for those primitive fields.
> 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
