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 Fri, 17 Feb 2012 11:35:59 GMT


Gilles commented on MATH-742:

bq. It is perfectly fine to make only part of the library Serializable.

And the policy must provide an clear decision-making procedure to select between the part
that will be "Serializable" and the one that won't.
We are already in trouble, because of this lack of policy, for several classes for which "Serializable"
is a supposedly innocuous feature (e.g. fields that should be transient cannot be because
no _explicit_ serialization is implemented).
In the Commons project, there is a commitment that minor releases must be fully compatible;
that implies that relying on a default serialization would prevent *any* change to internal
structure of a class.
Maybe that you are not aware of the constraints imposed by "Serializable"; maybe that you
don't care because in your use-case, you'll never be confronted to the problem of a wrong
serialized form. But another user's use-case might bring him here complaining about our inconsistent
support of "Serializable". Would he be less right than you?
It is always trivial to add "implements Serializable" to a class definition. But it is not
trivial to do the implementation in the right way; just adding "implements Serializable" is
not the right way, never. Again, it could be good enough for some purpose, but the wish for
CM to be an example of good Java programming, is not compatible with statements such as "We
know it's sloppy, so don't use it whenever you need something that works...".

The purpose of CM is to provide robust implementations of mathematical utilities; supporting
distributed applications is a totally different game.
Easing the use of CM in distributed applications is a worthy enhancement, but it should not
put the primary goal at risk (like blocking development because it would be tied by "puny"
considerations of backwards compatibility not even related to the "core business").
Hence I think that it has to be thought about with more care than was done up to now: You
rightly pointed out the inconsistency of tagging "PolynomialFunction" as serializable while
"PolynomialSplineFunction" is not. Personally, I'm really _not_ attached to backwards compatibility!
So I wouldn't mind making that class "Serializable" *until* we decide to clean up the mess.
Thus, if I have it my way, that would mean that in, say, version 4.0, *all* of the CM classes
(not obviously meant as data storage) will be stripped of their "trivial serializability".

> 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