[
https://issues.apache.org/jira/browse/MATH-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13210192#comment-13210192
]
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: 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
