commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [Math] Serializable (again)
Date Tue, 08 May 2012 20:57:21 GMT
On Tue, May 08, 2012 at 08:43:53PM +0200, Thomas Neidhart wrote:
> On 05/08/2012 01:44 PM, Gilles Sadowski wrote:
> > Sorry to correct you: It was removed because it was not implemented
> > properly. As a matter of principle, it is better to not support something
> > rather to give a false sense of what can be done with the code.
> I do not want to start a heated discussion on this topic again, but I
> would like to know what you mean with: it was not implemented properly.

There was a heated discussion here:

> The class in question contains a double and a double array. Making it
> serializable with a serialVersionUID is everything you need to do, or am
> I missing something important?
[And the reference.]

> > Of course, you are welcome to work on this functionality if you want to add
> > proper support to CM.
> > 
> > I started this thread with the same question as was pending from the last
> > time this issue was raised: What policy do we settle on?
> > 
> > For the moment we have (IIUC):
> >  * proper support: Sebb, Gilles
> >  * "sloppy" (no judgement implied ;-) implementation: Luc
> > 
> > If proper support is selected, then any attempt to introduce "implements
> > Serializable" that falls short (e.g. missing tags as reminded by Sebb, and
> > unit tests[1]) should be vetoed.
> It think your use of words does not reflect what people have in mind
> when talking about this issue. "sloppy" implies careless use of
> serialization, something I am pretty sure luc does not have in mind
> (actually I know considering his other works).

"Sloppy" is the right term, not to be dismissive, but to reflect "good
enough for what I need in my application", which might not be good enough
for a (supposed to be) state-of-the-art library.

> otoh, the tags as mentioned by sebb are also not "the" solution to the
> problem imho. I fail to find a practical use of them, and know at least
> of one open-source project that bans their use by policy.

Maybe that you are right; I'm no expert. And I would also tend to make a
sloppy usage of serialization whenever I need it!

I just think that "serialization" is not a necessity for CM, and that it is
too time-consuming to maintain for what it's worth.
[As S├ębastien said, there are other priorities...]

> But, I guess we will never come to a conclusion on this topic, so thats
> why I wrote that things should be kept as they are as long as there are
> no complaints about their malfunction. In fact there are several issues
> that talk about missing serialization support, and none that complains
> about broken support. ;-)

It depends on what you mean by "support". Back to the policy question.
We can choose to provide partial support, but _that_ would in fact be broken
support. We know it, now; and who is going to fix it when someone complains?

Rather let people select an appropriate tool for the task at hand: CM for
for computing the results and something else for serializing them.
[My view is that we should preferrably have the CM code stay (or become)
cleaner (and thus more maintainable) rather than spare a few additional
lines in user's code.]

-0 for solving such issues in the sloppy way (just indicate in the Javadoc
   that is so: No future/backward/cross version compatibility whatsoever).

Best regards,

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message