commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <>
Subject Re: [Math] Serializable (again)
Date Sat, 12 May 2012 15:30:54 GMT
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 <>
>>> 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
> This class was made serializable as of r748274 (2009-02-26,
> 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 <>, were
> a SerializablePair class was mentioned). The SerializablePair class was
> created as of r1079545 (2011-03-11,
> <>) and
> deleted 16 days later as of r1086045 according to MATH-551 (2011-03-27,
> <>).
> 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 

- Jörg

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

View raw message