Le 12/05/2012 19:10, Gilles Sadowski a écrit :
>> [...]
>>>
>>> I have tried to set up a clean serialization process for the classes
>>> that needs it, starting with the PointValuePair class as requested in
>>> [MATH-787].
>>>
>>> It turns out several previous choices completely prevent this to be done.
>>>
>>> At the beginning, we had a PointCostPair (created when the mantissa
>>> library was imported in 2006), which was then renamed
>>> ScalarPointValuePair in 2009, then RealPointValuePair a few days later
>>> until 2012 (see
>>>
>> <http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/optimization/RealPointValuePair.java?view=log&pathrev=1243185>).
>>> This class was made serializable as of r748274 (2009-02-26,
>>>
>> <http://svn.apache.org/viewvc/commons/proper/math/trunk/src/java/org/apache/commons/math/optimization/PointValuePair.java?r1=748274&r2=746504&pathrev=748274>).
>>>
>>> This class was renamed PointValuePair and changed to extend
>>> Pair<double[], Double> as of r1243186 on 2012-02-12. At that time, it
>>> lost is serializble feature since base class Pair is not serializable.
>>> The problem is that it is now impossible to add this feature back
>>> because Pair<K,V> also misses a no-arg constructor (which is fine
>>> because it must be immutable and we cannot enforce K and V to be
>>> serializable).
>>>
>>> This problem of Pair serialization was already encountered a few months
>>> ago (see discussion <http://markmail.org/thread/7fghomgsvayplhmb>, were
>>> a SerializablePair class was mentioned). The SerializablePair class was
>>> created as of r1079545 (2011-03-11,
>>> <http://svn.apache.org/viewvc?view=revision&revision=1079545>) and
>>> deleted 16 days later as of r1086045 according to MATH-551 (2011-03-27,
>>> <http://svn.apache.org/viewvc?view=revision&revision=1086045>).
>>>
>>> In order to fix bug MATH-787 and to recover the lost functionality of
>>> serializing the simple containers similar to PointValuePair, I would
>>> suggest we drop the inheritance from Pair<K,V> (because we *cannot*
>>> enforce serialization for this base class dur to its generic nature). We
>>> do not need this inheritance to Pair<K,V> here. It brings no added value
>>> to the class.
>
> Hmm, a "PointValuePair" is not a "Pair"... That's an original view. :-)
I am not sure whether this was an attempt at humor or not.
My point is not that PointValuePair is not a pair (without uppercase).
My point is that the base Pair class does not bring anything here. This
base class provides getKey, getValue methods, equals and hashcode
methods. The notion of pair has nothing to do with keys, but I think
this came from the original Map.Entry this class did implement long ago.
It also has nothing to do with values, but in this case this term fits
well. So of the four methods provided by Pair, two are unneeded, one
simple accessor is badly named, and the other accessor is good but this
seems to be by accident. So Pair as a base class serves no purposes
here. Setting PointValuePair a subclass of Pair only because of the name
or the fact it has two attributes is stretching inheritance too far.
In this case, it also complicates other things (here serialization).
As there is a solution for this (provided by Jörg and yourself), I will
use this and let this inheritance as is. I am not happy with this
complex solution which seems to me over-enginneering, but I will use it.
Luc
>
>>> Droping this inheritance would allow a clean and simple
>>> implementation of serialization. However, I fear this is an incompatible
>>> change (we cannot cast anymore to Pair).
>>>
>>> What do you think about it ?
>>
>> Use writeReplace/readResolve. All you need is a nested internal class that
>> transports the data:
>>
>> class UnserializableMe extends Aaargh implements Serializable {
>> Object writeReplace() {
>> return new SerializebleMe(dataToKeep);
>> }
>> private static class SerilizeableMe implements Serializable {
>> Object readResolve() {
>> return new UnserializebleMe(dataKept);
>> }
>> }
>> }
>>
>> Nobody cares what *is* actually written into the stream, especially if you
>> do not intent to support serialization between different versions of the
>> class.
>
> Thanks for the reminder; you prevented an unnecessary discussion! ;-)
>
> Luc,
> There is also the example I wrote there:
> https://issues.apache.org/jira/browse/MATH-742
>
>
> Best regards,
> Gilles
>
> ---------------------------------------------------------------------
> 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
