commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles (Commented) (JIRA)" <>
Subject [jira] [Commented] (MATH-742) Please make PolynomialSplineFunction Serializable
Date Sun, 19 Feb 2012 12:44:34 GMT


Gilles commented on MATH-742:

bq. I am not understanding what problems this could cause - can you give some explicit examples?
I don't know what your criteria are for "appropriate serialization code" - can you describe
a case where the default serialization code is not appropriate and why it is not appropriate?

I guess that the most trivial problem is serializing with some version of the library and
deserializing with another where the internal structure has changed in the meantime (e.g.
substituting one instance variable with another that would provide the same basic functionality).

Please note that the position which I am defending here is not based on "my" criteria for
how to handle "Serializable". I'm reporting concerns very well explained in the book "Effective
Java" by J. Bloch. Those concerns might be far-fetched and we are totally entitled to ignore
them in standalone applications but in the case of a _library_, we should not presume of the
innocuousness of anything we put in.

bq. As far as I can tell, the writeObject() and readObject() methods in ExceptionContext are
unnecessary because they simply do what the default mechanism does anyway (except that it
replaces throwing an exception for a non-serializable object with a String that says it is
non-serializable). What am I missing?

That the exception context is part of the exceptions defined in CM: If a non-"Serializable"
object is stored in the context, it must be detected, lest the default serialization generates
another exception, the result of which would be that the original exception cannot be propagated

Concerning your last series of points, there are answers at several different levels.
* Policy (as a means toward consistency of code design, implementation and maintenance): Cf.
previous posts.
* Resources: CM's core business is mathematical utilities programmed in clear OO Java code.
This alone is already too much for a small team. Adding more administrivia is IMHO unreasonable
* 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
* 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.

> Please make PolynomialSplineFunction Serializable
> -------------------------------------------------
>                 Key: MATH-742
>                 URL:
>             Project: Commons Math
>          Issue Type: Improvement
>    Affects Versions: 2.2
>            Reporter: Neil Roeth
>            Priority: Minor
>         Attachments:
> 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;}}
> and change this:
> {{public class PolynomialSplineFunction implements DifferentiableUnivariateRealFunction}}
> to this:
> {{public class PolynomialSplineFunction implements DifferentiableUnivariateRealFunction,
> 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:!default.jspa
For more information on JIRA, see:


View raw message