You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gilles Sadowski <gi...@harfang.homelinux.org> on 2012/02/10 20:40:34 UTC
[Math] Make everything "Serializable" ?
Hi.
This is an issue raised in relation to this JIRA ticket:
https://issues.apache.org/jira/browse/MATH-742
My position is that there should not be a discussion each time someone wants
a class to be "Serializable". Ideally, the rule should be clear enough that
the developer of a new class knows whether it should be made "Serializable"
or not.
Either we decide to not get in the way, ever, by making everything
"Serializable", or we think that some classes should be "Serializable" and
others should not, for some reason. [And IMHO that reason should be more
substantial than someone opening a ticket saying "Please make this class
Serializable because I need it".]
However, because the second alternative is likely to generate exhausting
debates not worth the energy, I shall stop even trying to defend this
point-of-view. ;)
Best regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Make everything "Serializable" ?
Posted by Thomas Neidhart <th...@gmail.com>.
On 02/11/2012 09:18 PM, Gilles Sadowski wrote:
> I would not draw that conclusion.
> As a Java library, it would not be wise for CM to move away from the OO
> paradigm. People who choose or use Java are accustomed to this programming
> style (or, even, like it ;-).
sure, I did not want to give the impression that OO in general is bad, I
just think that sometimes the OO idea is taken to the extreme and one
spends too much time trying to fit everything into objects ;-).
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Make everything "Serializable" ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Sat, Feb 11, 2012 at 07:35:25PM +0100, Thomas Neidhart wrote:
> On 02/11/2012 06:46 PM, Gilles Sadowski wrote:
>
> >[I still have to understand why objects that represent mathematical
> >algorithms must be serializable. It is quite possible that I miss somehing
> >but a use-case would help. In principle, I'd think that we must provide
> >accessors that would enable user code to re-construct any CM object; then
> >it's up to the user code to create any "Serializable" object for storing
> >those data they want to send over the wire, and reconstruct the CM object
> >on the other end...]
>
> I think you have a good point in general, but the case where this
> discussion started is not as clear-cut as this. In fact, many
> algorithms in CM are a mixture of data structures and algorithms
> bound together using OO paradigms, which may not be always the best
> solution.
When I mentioned data vs algorithms, I did not mean the "data" (instance
variables) that is part of the algorithm which in an OO approach, you bundle
together with the methods that operate on them.
I think that it is possible to distinguish objects which primarily represent
a (user-level) "data" structure from objects that represent algorithms
(e.g. something which is aimed a producing a result later on). An
example of the former would be an "Array2DRowRealMatrix" (from package
"linear"), an example of the latter would be a "Gaussian" (from package
"analysis.function").
While it is reasonable (IMO) to expect to serialize a matrix (a "data"
structure), it is not so for a "function"; the fact that it can contain
instance variables is due to an OO-programming feature, not to the concept
itself.
> So my conclusion would be to work on improving the code to be more
> functional and separate algorithms / data. In the mean time we can
> support the users by making their lives easier and support
> serialization by default where possible. If somebody has to work on
> a use-case that requires more sophisticated methods, well, he/she
> will have to find a solution anyway.
I would not draw that conclusion.
As a Java library, it would not be wise for CM to move away from the OO
paradigm. People who choose or use Java are accustomed to this programming
style (or, even, like it ;-).
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Make everything "Serializable" ?
Posted by Thomas Neidhart <th...@gmail.com>.
On 02/11/2012 06:46 PM, Gilles Sadowski wrote:
> [I still have to understand why objects that represent mathematical
> algorithms must be serializable. It is quite possible that I miss somehing
> but a use-case would help. In principle, I'd think that we must provide
> accessors that would enable user code to re-construct any CM object; then
> it's up to the user code to create any "Serializable" object for storing
> those data they want to send over the wire, and reconstruct the CM object
> on the other end...]
I think you have a good point in general, but the case where this
discussion started is not as clear-cut as this. In fact, many algorithms
in CM are a mixture of data structures and algorithms bound together
using OO paradigms, which may not be always the best solution.
So my conclusion would be to work on improving the code to be more
functional and separate algorithms / data. In the mean time we can
support the users by making their lives easier and support serialization
by default where possible. If somebody has to work on a use-case that
requires more sophisticated methods, well, he/she will have to find a
solution anyway.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Make everything "Serializable" ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> [...]
>
> However, adding Serializable still means devising and implementing the
> appropriate unit tests.
>
> ==
>
> I'm not saying don't do it, just that it involves a lot more work than
> might be obvious initially.
[Oh, I said that I would not fight over this... :-#]
But the arguments here make me raise at least a -0 on having a liberal use
of "implements Serializable". That would be a virtual -1 if we think that a
lot of resources are to be devoted to make (and check that) everything works
as advertised by the "Serializable" contract.
[I still have to understand why objects that represent mathematical
algorithms must be serializable. It is quite possible that I miss somehing
but a use-case would help. In principle, I'd think that we must provide
accessors that would enable user code to re-construct any CM object; then
it's up to the user code to create any "Serializable" object for storing
those data they want to send over the wire, and reconstruct the CM object
on the other end...]
Best,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Make everything "Serializable" ?
Posted by sebb <se...@gmail.com>.
On 11 February 2012 12:29, Luc Maisonobe <Lu...@free.fr> wrote:
> Le 11/02/2012 11:25, sebb a écrit :
>> On 11 February 2012 09:26, Luc Maisonobe <Lu...@free.fr> wrote:
>>> Hi,
>>>
>>> Le 11/02/2012 05:10, Bill Barker a écrit :
>>>> While the development team has exploded for [MATH], maintaining
>>>> Serializable interfaces is expensive and historically hasn't been kept
>>>> up.
>>>
>>> I don't agree.
>>>
>>> Maintaining serialization maintainance is hard only if you want to be
>>> able to deserialized with version n something that was serialized with
>>> version p. This situation appears either if you use serialization for
>>> long term storage or if you have a distributed application with two
>>> parts using different levels. The first case is a wrong use of
>>> serialization. The second case can be simply declared to be unsupported.
>>>
>>> Apart from that, maintaining serialization is updating serialVersionId,
>>> which we did (and IMHO it is no big deal if it is not done due to the
>>> reasons explained in previous paragraph).
>>
>> There's a bit more to it than that.
>>
>> If a class is updated to add new fields, these either need to be
>> serialisable themselves, or be marked transient.
>> And transient can only be used if the field is not needed until after
>> deserialisation.
>
> Yes, but checkstyle helps a lot detecting this.
Checkstyle (and Findbugs) warn you if the field is not serialisable.
Do they also warn you if a transient field is not set by deserialisation?
[Cannot remember offhand]
Even if so, each such report would have to be investigated to
establish whether it is OK to omit the field init or not, and if it is
OK to omit, this would need to be documented and the checkstyle config
updated to skip the warning.
>> Also, some consideration must be given to the serialised form, to
>> ensure it is appropriate.
>
> I don't understand, can you explain a little more ?
The default serialised form effectively copies the physical
representation of an object.
For simple objects that works fine, but for some data structures it
may be totally unsuitable.
An example from Effective Java [Bloch] is of a class that implements a
double-linked list of Strings.
The links are a big (and unnecessary) overhead on the serialised form;
only the Strings themselves really need to be passed across.
[The simple approach is to serialise the count, followed by the Strings].
Using the default serialisation will be a lot slower and may even
cause stack overflow as the default implementation uses recursive
traversal of the links.
Another example - serialising a hash table: hashes are not guaranteed
portable, so the deserialised form may be corrupt.
There's also the issue that de-serialisation does not use the
constructor, so any invariants which are established by the ctor (e.g.
non-null parameter) also need to be maintained by the readObject
method.
>>
>> Serialisation and final fields don't play well together.
>>
>>>> So I would go for requiring the user to do something like:
>>>>
>>>> public class MyPolynomialSplineFunction extends
>>>> PolynomialSplineFunction, implements Serializable {
>>>> private static long serialVersionUID = <something>;
>>>>
>>>> // put non-default constructors here
>>>> }
>>>
>>> I'm not sure it scales with more than one level of aggregation. What
>>> would happen if the user wants to serialize one of our top level objects
>>> that itself embeds one of our lower level objects ?
>>
>> Or indeed if PolynomialSplineFunction is final?
>>
>>>>
>>>> it is less than a minute to do this in eclipse, so it should be on the
>>>> user for classes like this.
>>>
>>> I am strongly in favor of putting Serialize where it can be put. Once
>>> again, it's not an absolute rule which should be done in one sweep, it's
>>> more a small low priority regular task to add serialize here and there
>>> as we see.
>>
>> Even without trying to maintain version compatibilty, adding
>> Serialisation can be non-trivial.
>>
>> It should also be tested - I don't think there are any unit tests yet.
>
> All step handlers in the ODE package are tested for serialization, as
> well as EmpiricalDistribution and the various descriptive statistics
> classes, polynomial function, complex, fractions, vectors, matrices ...
>
> There are even dedicated methods in TestUtils: serializeAndRecover and
> checkSerializedEquality.
OK, I'd not noticed those.
However, adding Serializable still means devising and implementing the
appropriate unit tests.
==
I'm not saying don't do it, just that it involves a lot more work than
might be obvious initially.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Make everything "Serializable" ?
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 11/02/2012 11:25, sebb a écrit :
> On 11 February 2012 09:26, Luc Maisonobe <Lu...@free.fr> wrote:
>> Hi,
>>
>> Le 11/02/2012 05:10, Bill Barker a écrit :
>>> While the development team has exploded for [MATH], maintaining
>>> Serializable interfaces is expensive and historically hasn't been kept
>>> up.
>>
>> I don't agree.
>>
>> Maintaining serialization maintainance is hard only if you want to be
>> able to deserialized with version n something that was serialized with
>> version p. This situation appears either if you use serialization for
>> long term storage or if you have a distributed application with two
>> parts using different levels. The first case is a wrong use of
>> serialization. The second case can be simply declared to be unsupported.
>>
>> Apart from that, maintaining serialization is updating serialVersionId,
>> which we did (and IMHO it is no big deal if it is not done due to the
>> reasons explained in previous paragraph).
>
> There's a bit more to it than that.
>
> If a class is updated to add new fields, these either need to be
> serialisable themselves, or be marked transient.
> And transient can only be used if the field is not needed until after
> deserialisation.
Yes, but checkstyle helps a lot detecting this.
> Also, some consideration must be given to the serialised form, to
> ensure it is appropriate.
I don't understand, can you explain a little more ?
>
> Serialisation and final fields don't play well together.
>
>>> So I would go for requiring the user to do something like:
>>>
>>> public class MyPolynomialSplineFunction extends
>>> PolynomialSplineFunction, implements Serializable {
>>> private static long serialVersionUID = <something>;
>>>
>>> // put non-default constructors here
>>> }
>>
>> I'm not sure it scales with more than one level of aggregation. What
>> would happen if the user wants to serialize one of our top level objects
>> that itself embeds one of our lower level objects ?
>
> Or indeed if PolynomialSplineFunction is final?
>
>>>
>>> it is less than a minute to do this in eclipse, so it should be on the
>>> user for classes like this.
>>
>> I am strongly in favor of putting Serialize where it can be put. Once
>> again, it's not an absolute rule which should be done in one sweep, it's
>> more a small low priority regular task to add serialize here and there
>> as we see.
>
> Even without trying to maintain version compatibilty, adding
> Serialisation can be non-trivial.
>
> It should also be tested - I don't think there are any unit tests yet.
All step handlers in the ODE package are tested for serialization, as
well as EmpiricalDistribution and the various descriptive statistics
classes, polynomial function, complex, fractions, vectors, matrices ...
There are even dedicated methods in TestUtils: serializeAndRecover and
checkSerializedEquality.
Luc
>
>> Luc
>>
>>>
>>> -----Original Message----- From: Gilles Sadowski
>>> Sent: Friday, February 10, 2012 11:40 AM
>>> To: dev@commons.apache.org
>>> Subject: [Math] Make everything "Serializable" ?
>>>
>>> Hi.
>>>
>>> This is an issue raised in relation to this JIRA ticket:
>>> https://issues.apache.org/jira/browse/MATH-742
>>>
>>> My position is that there should not be a discussion each time someone
>>> wants
>>> a class to be "Serializable". Ideally, the rule should be clear enough that
>>> the developer of a new class knows whether it should be made "Serializable"
>>> or not.
>>> Either we decide to not get in the way, ever, by making everything
>>> "Serializable", or we think that some classes should be "Serializable" and
>>> others should not, for some reason. [And IMHO that reason should be more
>>> substantial than someone opening a ticket saying "Please make this class
>>> Serializable because I need it".]
>>> However, because the second alternative is likely to generate exhausting
>>> debates not worth the energy, I shall stop even trying to defend this
>>> point-of-view. ;)
>>>
>>>
>>> Best regards,
>>> Gilles
>>>
>>> ---------------------------------------------------------------------
>>> 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
Re: [Math] Make everything "Serializable" ?
Posted by sebb <se...@gmail.com>.
On 11 February 2012 09:26, Luc Maisonobe <Lu...@free.fr> wrote:
> Hi,
>
> Le 11/02/2012 05:10, Bill Barker a écrit :
>> While the development team has exploded for [MATH], maintaining
>> Serializable interfaces is expensive and historically hasn't been kept
>> up.
>
> I don't agree.
>
> Maintaining serialization maintainance is hard only if you want to be
> able to deserialized with version n something that was serialized with
> version p. This situation appears either if you use serialization for
> long term storage or if you have a distributed application with two
> parts using different levels. The first case is a wrong use of
> serialization. The second case can be simply declared to be unsupported.
>
> Apart from that, maintaining serialization is updating serialVersionId,
> which we did (and IMHO it is no big deal if it is not done due to the
> reasons explained in previous paragraph).
There's a bit more to it than that.
If a class is updated to add new fields, these either need to be
serialisable themselves, or be marked transient.
And transient can only be used if the field is not needed until after
deserialisation.
Also, some consideration must be given to the serialised form, to
ensure it is appropriate.
Serialisation and final fields don't play well together.
>> So I would go for requiring the user to do something like:
>>
>> public class MyPolynomialSplineFunction extends
>> PolynomialSplineFunction, implements Serializable {
>> private static long serialVersionUID = <something>;
>>
>> // put non-default constructors here
>> }
>
> I'm not sure it scales with more than one level of aggregation. What
> would happen if the user wants to serialize one of our top level objects
> that itself embeds one of our lower level objects ?
Or indeed if PolynomialSplineFunction is final?
>>
>> it is less than a minute to do this in eclipse, so it should be on the
>> user for classes like this.
>
> I am strongly in favor of putting Serialize where it can be put. Once
> again, it's not an absolute rule which should be done in one sweep, it's
> more a small low priority regular task to add serialize here and there
> as we see.
Even without trying to maintain version compatibilty, adding
Serialisation can be non-trivial.
It should also be tested - I don't think there are any unit tests yet.
> Luc
>
>>
>> -----Original Message----- From: Gilles Sadowski
>> Sent: Friday, February 10, 2012 11:40 AM
>> To: dev@commons.apache.org
>> Subject: [Math] Make everything "Serializable" ?
>>
>> Hi.
>>
>> This is an issue raised in relation to this JIRA ticket:
>> https://issues.apache.org/jira/browse/MATH-742
>>
>> My position is that there should not be a discussion each time someone
>> wants
>> a class to be "Serializable". Ideally, the rule should be clear enough that
>> the developer of a new class knows whether it should be made "Serializable"
>> or not.
>> Either we decide to not get in the way, ever, by making everything
>> "Serializable", or we think that some classes should be "Serializable" and
>> others should not, for some reason. [And IMHO that reason should be more
>> substantial than someone opening a ticket saying "Please make this class
>> Serializable because I need it".]
>> However, because the second alternative is likely to generate exhausting
>> debates not worth the energy, I shall stop even trying to defend this
>> point-of-view. ;)
>>
>>
>> Best regards,
>> Gilles
>>
>> ---------------------------------------------------------------------
>> 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
Re: [Math] Make everything "Serializable" ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hello.
> >
> > "Serializable" is a lot of work indeed: cf. revision 1245003, where the
> > change was to fix bugs detected by "FindBugs":
> > ---CUT---
> > The field org.apache.commons.math3.random.ISAACRandom.arr is transient but
> > isn't set by deserialization
> > ---CUT---
>
> OK. The consensus seems to be to not make everything serializable.
> Do we set Serializable on a case by case basis (hence solving issue
> MATH-742) ?
How do want to solve it?
IMHO, "PolynomialSplineFunction" the perfect example for not being
"Serializable": It is a function, not a data storage object.
And it already provides the necessary accessors ("getKnots" and
"getPolynomials"[1]) for users to
1. save the state in their own data storage structure,
2. serialize however they want it (cf. Ted's opinion about "Serializable"),
3. reconstruct the object using the normal constructors.
In any scenario like the above, I would *not* have the class
"Serializable".[2]
Best regards,
Gilles
[1] And "PolynomilaFunction" provides "getCoefficients" (should thus not be
"Serializable" either).
[2] On the other hand, there was a compelling scenario for having the CM
"ExceptionContext" serializable.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Make everything "Serializable" ?
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 16/02/2012 15:47, Gilles Sadowski a écrit :
> Hi.
>
> "Serializable" is a lot of work indeed: cf. revision 1245003, where the
> change was to fix bugs detected by "FindBugs":
> ---CUT---
> The field org.apache.commons.math3.random.ISAACRandom.arr is transient but
> isn't set by deserialization
> ---CUT---
OK. The consensus seems to be to not make everything serializable.
Do we set Serializable on a case by case basis (hence solving issue
MATH-742) ?
Luc
>
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> 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
Re: [Math] Make everything "Serializable" ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hi.
"Serializable" is a lot of work indeed: cf. revision 1245003, where the
change was to fix bugs detected by "FindBugs":
---CUT---
The field org.apache.commons.math3.random.ISAACRandom.arr is transient but
isn't set by deserialization
---CUT---
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Make everything "Serializable" ?
Posted by Ted Dunning <te...@gmail.com>.
No. I never use Java serialization if I can help it.
On Sat, Feb 11, 2012 at 8:57 AM, Gilles Sadowski <
gilles@harfang.homelinux.org> wrote:
> On Sat, Feb 11, 2012 at 08:31:53AM -0800, Ted Dunning wrote:
> > Interesting that you say that because long-term storage of data and
> > communication between distributed components are exactly what I use
> > serialization for. Note that communication between components almost
> > automatically implies version mismatch in lots of production systems
> > exactly because you can't update all components simultaneously.
> >
> > Systems like Avro, Thrift, Protobufs and Kryo all exist precisely because
> > native serialization is so terribly broken.
>
> Do you mean that you use a broken system for long-term storage?
>
Re: [Math] Make everything "Serializable" ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Sat, Feb 11, 2012 at 08:31:53AM -0800, Ted Dunning wrote:
> Interesting that you say that because long-term storage of data and
> communication between distributed components are exactly what I use
> serialization for. Note that communication between components almost
> automatically implies version mismatch in lots of production systems
> exactly because you can't update all components simultaneously.
>
> Systems like Avro, Thrift, Protobufs and Kryo all exist precisely because
> native serialization is so terribly broken.
Do you mean that you use a broken system for long-term storage?
Gilles
> On Sat, Feb 11, 2012 at 1:26 AM, Luc Maisonobe <Lu...@free.fr>wrote:
>
> > Maintaining serialization maintainance is hard only if you want to be
> > able to deserialized with version n something that was serialized with
> > version p. This situation appears either if you use serialization for
> > long term storage or if you have a distributed application with two
> > parts using different levels. The first case is a wrong use of
> > serialization. The second case can be simply declared to be unsupported.
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Make everything "Serializable" ?
Posted by Ted Dunning <te...@gmail.com>.
Interesting that you say that because long-term storage of data and
communication between distributed components are exactly what I use
serialization for. Note that communication between components almost
automatically implies version mismatch in lots of production systems
exactly because you can't update all components simultaneously.
Systems like Avro, Thrift, Protobufs and Kryo all exist precisely because
native serialization is so terribly broken.
On Sat, Feb 11, 2012 at 1:26 AM, Luc Maisonobe <Lu...@free.fr>wrote:
> Maintaining serialization maintainance is hard only if you want to be
> able to deserialized with version n something that was serialized with
> version p. This situation appears either if you use serialization for
> long term storage or if you have a distributed application with two
> parts using different levels. The first case is a wrong use of
> serialization. The second case can be simply declared to be unsupported.
>
Re: [Math] Make everything "Serializable" ?
Posted by Luc Maisonobe <Lu...@free.fr>.
Hi,
Le 11/02/2012 05:10, Bill Barker a écrit :
> While the development team has exploded for [MATH], maintaining
> Serializable interfaces is expensive and historically hasn't been kept
> up.
I don't agree.
Maintaining serialization maintainance is hard only if you want to be
able to deserialized with version n something that was serialized with
version p. This situation appears either if you use serialization for
long term storage or if you have a distributed application with two
parts using different levels. The first case is a wrong use of
serialization. The second case can be simply declared to be unsupported.
Apart from that, maintaining serialization is updating serialVersionId,
which we did (and IMHO it is no big deal if it is not done due to the
reasons explained in previous paragraph).
> So I would go for requiring the user to do something like:
>
> public class MyPolynomialSplineFunction extends
> PolynomialSplineFunction, implements Serializable {
> private static long serialVersionUID = <something>;
>
> // put non-default constructors here
> }
I'm not sure it scales with more than one level of aggregation. What
would happen if the user wants to serialize one of our top level objects
that itself embeds one of our lower level objects ?
>
> it is less than a minute to do this in eclipse, so it should be on the
> user for classes like this.
I am strongly in favor of putting Serialize where it can be put. Once
again, it's not an absolute rule which should be done in one sweep, it's
more a small low priority regular task to add serialize here and there
as we see.
Luc
>
> -----Original Message----- From: Gilles Sadowski
> Sent: Friday, February 10, 2012 11:40 AM
> To: dev@commons.apache.org
> Subject: [Math] Make everything "Serializable" ?
>
> Hi.
>
> This is an issue raised in relation to this JIRA ticket:
> https://issues.apache.org/jira/browse/MATH-742
>
> My position is that there should not be a discussion each time someone
> wants
> a class to be "Serializable". Ideally, the rule should be clear enough that
> the developer of a new class knows whether it should be made "Serializable"
> or not.
> Either we decide to not get in the way, ever, by making everything
> "Serializable", or we think that some classes should be "Serializable" and
> others should not, for some reason. [And IMHO that reason should be more
> substantial than someone opening a ticket saying "Please make this class
> Serializable because I need it".]
> However, because the second alternative is likely to generate exhausting
> debates not worth the energy, I shall stop even trying to defend this
> point-of-view. ;)
>
>
> Best regards,
> Gilles
>
> ---------------------------------------------------------------------
> 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
Re: [Math] Make everything "Serializable" ?
Posted by Bill Barker <bi...@verizon.net>.
While the development team has exploded for [MATH], maintaining Serializable
interfaces is expensive and historically hasn't been kept up. So I would go
for requiring the user to do something like:
public class MyPolynomialSplineFunction extends PolynomialSplineFunction,
implements Serializable {
private static long serialVersionUID = <something>;
// put non-default constructors here
}
it is less than a minute to do this in eclipse, so it should be on the user
for classes like this.
-----Original Message-----
From: Gilles Sadowski
Sent: Friday, February 10, 2012 11:40 AM
To: dev@commons.apache.org
Subject: [Math] Make everything "Serializable" ?
Hi.
This is an issue raised in relation to this JIRA ticket:
https://issues.apache.org/jira/browse/MATH-742
My position is that there should not be a discussion each time someone wants
a class to be "Serializable". Ideally, the rule should be clear enough that
the developer of a new class knows whether it should be made "Serializable"
or not.
Either we decide to not get in the way, ever, by making everything
"Serializable", or we think that some classes should be "Serializable" and
others should not, for some reason. [And IMHO that reason should be more
substantial than someone opening a ticket saying "Please make this class
Serializable because I need it".]
However, because the second alternative is likely to generate exhausting
debates not worth the energy, I shall stop even trying to defend this
point-of-view. ;)
Best regards,
Gilles
---------------------------------------------------------------------
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