Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Sun, 19 Feb 2012 15:42:34 +0000 (UTC)
From: "Neil Roeth (Commented) (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: 
 <1717673791.443.1329666154386.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <766734969.20720.1328816640283.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (MATH-742) Please make PolynomialSplineFunction
 Serializable
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/MATH-742?page=3Dcom.atlassian.j=
ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D132113=
88#comment-13211388 ]=20

Neil Roeth commented on MATH-742:
---------------------------------

Responding to Luc:

bq. I think we can simply say this is not supported. Serialization should n=
ot be used for long time storage, and even if it can be used for distribute=
d computation with different versions between client and server, we can sim=
ply say we don't support it.

Completely reasonable.

bq. +1 for the concerns of a library, but there are many cases when a simpl=
e "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" accesso=
rs in order to extract the objectively meaningful data that are needed to d=
efine the concept represented by "PolynomialSplineFunction" (the knots and =
the set of coefficients of the polynomial functions that are connected at t=
he knots).

Well, yes, but add a private field critical to the state of PolynomialFunct=
ion and the idiom breaks down.  There would be no breakdown if the class it=
self were responsible for ensuring that readObject() and writeObject() did =
the right thing.

Here's an example: Suppose you have a random number generator class RngGill=
es that has a constructor that takes a single long integer as an argument. =
 The constructor precondition returns true for any value of the long intege=
r.  With that long integer, it initializes a private table of several hundr=
ed long integers and a private marker of its current position in the table.=
  When RngGilles.nextRandom() is called, it calculates the value to be retu=
rned from the table and its current place in the table , then updates the t=
able 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 t=
o 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 becau=
se the object is deserialized without undergoing the constructor's precondi=
tion 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 exa=
ct same state as the object that was serialized, so since it already satisf=
ied any constructor preconditions when it was first created, there is no ne=
ed to check them again.  It is, of course, possible to subvert this for som=
e particular class, e.g., through poorly written explicit writeObject() and=
 readObject() methods, or by failing to mark some fields transient and maki=
ng methods that use the transient field handle that, but I'd call that a bu=
g in that particular object's serialization implementation, not a general f=
ailure of serialization that needs to be handled outside the class by seria=
lization wrappers.  ISTM that the idiom basically boils down to deconstruct=
ing objects to their primitive fields and then reconstructing them from tho=
se primitives, completely bypassing the whole Serialization mechanism excep=
t for those primitive fields.
               =20
> 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 Poly=
nomialFunction class in the same package is. All that needs to be done is t=
o add the import:
> {{import java.io.Serializable;}}
> and change this:
> {{public class PolynomialSplineFunction implements DifferentiableUnivaria=
teRealFunction}}
> to this:
> {{public class PolynomialSplineFunction implements DifferentiableUnivaria=
teRealFunction, Serializable}}
> I made exactly that modification to a local copy and it serialized succes=
sfully.  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 administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira