Luc Maisonobe wrote:
> Hi all,
>
> Le 09/05/2012 13:41, Gilles Sadowski a écrit :
>> On Wed, May 09, 2012 at 07:03:58AM -0400, James Carman wrote:
>>> On Wed, May 9, 2012 at 3:03 AM, Luc Maisonobe <luc.maison...@free.fr>
>>> wrote:
>>>>> Is there such a thing as short-term serialization?
>>>>
>>>> Yes, of course, and this what many people need. This is what James
>>>> called marshalling/unmarshalling. This is a standard way to communicate
>>>> between some applications that share a common basis. Of course [math]
>>>> is not a distributed computing environment, but it should not prevent
>>>> people from being used in a distributed environment.
>>>>
>>>
>>> For long-term serialization needs, I would suggest instead that we
>>> introduce (perhaps it's there already, I'm not familiar with the
>>> entire codebase) exporters/importers [...]
>>
>> There is some (see e.g. in "o.a.c.m.linear.MatrixUtils").
>>
>> But even those shows the unfortunate discrepancy between the quality
>> levels of different aspects of the library: While we aim at
>> state-of-the-art implementations of the mathematical algorithms,
>> serialization, among other things, only aims at "good enough for trivial
>> uses" (e.g. the current matrix importer/exporter would probably be
>> useless for sparse matrices).
>>
>> OK, it's there and it could be useful to users of CM, but IMHO we should
>> not push in that direction by adding more and more "sub-par"
>> functionalities.
>>
>>> which support some
>>> industry-standard file format(s) (such as those used by R for
>>> example).
>>
>> I dont' know "R" but nonetheless agree on the "industry-standard".
>> That's not the case currently.
>>
>> The problem we face here, as in other discussions (e.g.
>> monitoring/logging), is the feature/drawback of "no dependencies".
>>
>> My view is that we should be consistent:
>> * either we stick to "no dependencies" and it goes with not introducing
>> anything beyond the core business (that are the math algorithms), or
>> * we provide more facilities for users but those should also be
>> state-of-the-art and thus provided through tools recognized as the best
>> in their category.
>
> 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. 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.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
