commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien Brisard <sebastien.bris...@m4x.org>
Subject Re: [math] Serializable transforms (MATH-677)?
Date Wed, 04 Jan 2012 09:35:10 GMT
2012/1/4 Luc Maisonobe <Luc.Maisonobe@free.fr>:
> Le 04/01/2012 10:06, Sébastien Brisard a écrit :
>> 2012/1/4 Luc Maisonobe <Luc.Maisonobe@free.fr>:
>>> Le 04/01/2012 02:21, Sébastien Brisard a écrit :
>>>> Hi,
>>>> I'm currently working on MATH-677 (cleaning-up o.a.c.m.transforms). I
>>>> notice that all classes in this package implement Serializable. I'm
>>>> wondering whether there is a practical use for this. If not, I would
>>>> rather remove this functionality. What do you think?
>>>
>>> I like to have everything serializable (but probably belong to a
>>> minority here). My rationale is that when a user put one of our class as
>>> a field in its own classes and need his classes to be serializable, he
>>> needs to have our classes serializable. This also is almost never a
>>> problem to add this, as it is often simply a matter of declaring an
>>> interface and putting a static serializable ID field.
>>>
>>> I use it a lot for ODE step handlers for example, as it allows to store
>>> the complete history thoughout an integration run and reuse it later. As
>>> there are pointers back and forth between various parts (step handlers,
>>> events handlers, integrator ...) many classes in this package must be
>>> serializable. I guess similar rationale may apply to other packages.
>>>
>>> Luc
>>>
>> Actually, I didn't realize that the use-case you are talking about
>> could apply to my simulations as well... which make heavy use of FFTs.
>> So maybe it's better to keep this functionality. Only, I need to be
>> very rigorous with serial version uids ;). Or is it at release time
>> that we care about regenerating these numbers? Is this task somehow
>> automated?
>
> No, the task is not fully automated. I used to rely on eclipse
> generation for this (i.e. I suppressed the field, and when eclipse fired
> a warning I selected an automatic generation in its warning quick fix
> context menu.
>
> However, since then there has been a discussion on the list and it was
> suggested to simply use the date of last file edition for that, in a
> format like 20120104 for todays date for example. This has the
> additional advantage that it provides a hint to know when the class had
> a large change involving fields modifications for example.
>
I was thinking of a tool (mvn plugin?) which would automatically
detect that the UID of a specific class needs to be updated (based on
the analysis of the changes operated on the class). I'm probably
dreaming, though... I'll try and remember to do it each time I commit
a change which requires updates.
Sébastien
> Luc
>
>>
>> Sébastien
>>
>>>>
>>>> Sébastien
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message