Hello, 2012/5/8 Thomas Neidhart <thomas.neidh...@gmail.com>: > On Tue, May 8, 2012 at 12:24 PM, Gilles Sadowski < > gil...@harfang.homelinux.org> wrote: > >> > I am in favor of this second option: add Serializable were needed upon >> > > request. >> > >> > +1 >> > > +1 > > >> > > In this case, the request seems fair as the class is mainly a >> > > simple container for two values. >> > >> > But what ever the size/complexity, adding Serializable needs to be >> > done carefully, and documented as necessary using @serial, >> > @serialField, @serialData tags. >> >> > > >> I am _not_ going to work on that. [Plenty of arguments given previously >> saying exactly that: it must be done seriously. It is not so in CM. And >> (IMHO) it is not necessary for CM to support "Serializable" (also argued >> previously).] >> >> > Just adding "implements Serializable" is a bad idea. >> >> Agreed. >> >> So? [I guess I'm not going to do anything myself on this issue.] >> > > I think we should implement it where it is requested and makes sense (like > results of a computation). But then in a proper way (should be defined in > the developers guide or even the wiki as best practice to follow). > For other cases we can just skip it, but please, do not remove Serializable > just because you don't like it (as it happened in the case for the > referenced issue). > > Thomas I have mixed feelings on this issue. I guess that everyone agrees that serialization must be done properly. Like Gilles, I'm not going to work on this issue, probably for other reasons 1. I certainly do not have the required expertise (and do not have the time to acquire it at the moment). Which makes me wonder about maintenance of serializable classes. Committers like myself reviewing other people's patches on serializable classes, might well be innocently committing a patch which should not be. To prevent that, we should make sure that we do have some "serialization referees" in the CM community, which might overload these people. 2. I think there are many more urgent issues (only my opinion, though), like the open issues about precision in the distribution package, or the implementation of more special functions, which is a quite time consuming, but necessary task. Best regards, Sébastien
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
