Le 11/02/2012 11:25, sebb a écrit :
> On 11 February 2012 09:26, Luc Maisonobe <luc.maison...@free.fr> wrote:
>> 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).
>
> There's a bit more to it than that.
>
> If a class is updated to add new fields, these either need to be
> serialisable themselves, or be marked transient.
> And transient can only be used if the field is not needed until after
> deserialisation.
Yes, but checkstyle helps a lot detecting this.
> Also, some consideration must be given to the serialised form, to
> ensure it is appropriate.
I don't understand, can you explain a little more ?
>
> Serialisation and final fields don't play well together.
>
>>> 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 ?
>
> Or indeed if PolynomialSplineFunction is final?
>
>>>
>>> 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.
>
> Even without trying to maintain version compatibilty, adding
> Serialisation can be non-trivial.
>
> It should also be tested - I don't think there are any unit tests yet.
All step handlers in the ODE package are tested for serialization, as
well as EmpiricalDistribution and the various descriptive statistics
classes, polynomial function, complex, fractions, vectors, matrices ...
There are even dedicated methods in TestUtils: serializeAndRecover and
checkSerializedEquality.
Luc
>
>> 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
>>
>
> ---------------------------------------------------------------------
> 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
