Hi,
Le 11/02/2012 05:10, Bill Barker a écrit :
> While the development team has exploded for [MATH], maintaining
> Serializable interfaces is expensive and historically hasn't been kept
> up.
I don't agree.
Maintaining serialization maintainance is hard only if you want to be
able to deserialized with version n something that was serialized with
version p. This situation appears either if you use serialization for
long term storage or if you have a distributed application with two
parts using different levels. The first case is a wrong use of
serialization. The second case can be simply declared to be unsupported.
Apart from that, maintaining serialization is updating serialVersionId,
which we did (and IMHO it is no big deal if it is not done due to the
reasons explained in previous paragraph).
> So I would go for requiring the user to do something like:
>
> public class MyPolynomialSplineFunction extends
> PolynomialSplineFunction, implements Serializable {
> private static long serialVersionUID = <something>;
>
> // put non-default constructors here
> }
I'm not sure it scales with more than one level of aggregation. What
would happen if the user wants to serialize one of our top level objects
that itself embeds one of our lower level objects ?
>
> it is less than a minute to do this in eclipse, so it should be on the
> user for classes like this.
I am strongly in favor of putting Serialize where it can be put. Once
again, it's not an absolute rule which should be done in one sweep, it's
more a small low priority regular task to add serialize here and there
as we see.
Luc
>
> -----Original Message----- From: Gilles Sadowski
> Sent: Friday, February 10, 2012 11:40 AM
> To: dev@commons.apache.org
> Subject: [Math] Make everything "Serializable" ?
>
> Hi.
>
> This is an issue raised in relation to this JIRA ticket:
> https://issues.apache.org/jira/browse/MATH-742
>
> My position is that there should not be a discussion each time someone
> wants
> a class to be "Serializable". Ideally, the rule should be clear enough that
> the developer of a new class knows whether it should be made "Serializable"
> or not.
> Either we decide to not get in the way, ever, by making everything
> "Serializable", or we think that some classes should be "Serializable" and
> others should not, for some reason. [And IMHO that reason should be more
> substantial than someone opening a ticket saying "Please make this class
> Serializable because I need it".]
> However, because the second alternative is likely to generate exhausting
> debates not worth the energy, I shall stop even trying to defend this
> point-of-view. ;)
>
>
> Best regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
