2012/1/4 Luc Maisonobe <luc.maison...@free.fr>: > Le 04/01/2012 10:06, Sébastien Brisard a écrit : >> 2012/1/4 Luc Maisonobe <luc.maison...@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-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
