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 23:52:34 GMT


Gilles commented on MATH-742:

According to the general convention, this discussion should be ported to the "dev" ML, possibly
with a subject prefix of "[ALL]" so that we can get opinions of people who are much more knowledgeable
than me on the pros and cons of supporting serialization.

After I respond to the last points raised here, we could maybe suspend the comments in this

Adding an "implements Serializable" on a case-by-case basis is not a substitute for a policy
(i.e. defining what would be the ideal state for CM). Personally, I think that it will not
help users in the long-term, because they will know (because we'll tell them) that they should
not rely on a serialization policy that reads "{{Serializable}} is added for your convenience
but is otherwise unsupported".

I don't understand why the idiom would break down with the addition of a private field; the
only requirement is that a class provides accessors to everything one needs to reconstruct
an identical object.

Could you give a concrete example where one would need to serialize a RNG (where it must continue
drawing from the same sequence)?

There is one subversion which you did not mention (which is the one that usually comes up
when the experts talk about serialization) is the possible corruption (accidental or intentional)
that could happen while the data goes over the wire. That's what the idiom can thwart.
On the other hand, you enumerate many sources of possible bugs in the implementation of serialization:
That's exactly why I say that _we_ should not implement it, unless we have people on the team
that can commit to support it! But that would come back to the issue of policy, having a discussion
on the "dev" ML about what should be the serialized form, which classes should be serializable
and which not, how to decide for border-line cases, etc.
That's a moderately ambitious project. IMHO, it is people like you, that would benefit from
it, who should primarily contribute to it, even if just to start the discussion on the ML
to get on the right track.
As I told at the beginning, the issue is not simply to add "implements Serializable" to "PolynomialSplienFunction",
even if the current lack of consistency in CM would have you believed that it was, for which
we apologize. ;-)

> 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