I don't know that you want to get into supporting long-term serialization support. I would say CM should support transient serialization (if that makes any sense), such as marshalling/unmarshalling. If you guarantee long-term serialization support (reading data from serialized for much later, perhaps by another version of CM), then we get into the nasty serialization test cases like Commons Collections has/had. Yuck!
On Tue, May 8, 2012 at 2:43 PM, Thomas Neidhart <thomas.neidh...@gmail.com> 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. > > 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? > >> 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). > > 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. > > 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. ;-) > > Good evening > > Thomas > > --------------------------------------------------------------------- > 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
