commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Neil Roeth (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MATH-742) Please make PolynomialSplineFunction Serializable
Date Sun, 19 Feb 2012 15:42:34 GMT

    [ 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

       

Mime
View raw message