commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [math] Does this break the API?
Date Fri, 09 Mar 2012 07:48:53 GMT
Le 09/03/2012 08:14, Sébastien Brisard a écrit :
> Dear all,

Hi Sébastien,

> I'm extremely unfamiliar with serialization and its many pitfalls, and
> I would need advice from you wise guys ;-) !!!
> Here is the thing. I'm currently working on MATH-761, where for the
> sake of "efficiency" (which remains to be asserted [1]), I did some
> bad choice on the structure of internal data. I'm willing to clean
> this up. The way I see it at the moment, the nested class SymmLQ.State
> will probably (probably) go, as it conveys a false sense of security
> through encapsulation (not sure I'm very clear, there. In other words:
> the code is difficult to read).
> This class is private, so the public API would not be broken. However,
> there is another nested class, namely SymmLQ.SymmLQEvent which
> implements Serializable, and currently holds a reference to an
> instance of State. So, I guess that if State disappears in 3.1, events
> serialized with 3.0 could not be retrieved with CM v 3.1 (and
> vice-versa). Would this be considered as a break of the API?

I don't think so.
As decided on this list, we almost don't support serialization. In the
few places where it is supported, we should not guaranteed any
cross-version compatibility.

best regards,

> Sorry if this is a silly question, and thanks in advance for your help!
> Best regards,
> Sébastien
> [1] Thinking about it a few months later, I now realize that my quest
> for efficiency was actually completely flawed: I wanted to avoid the
> creation of one small object at each iteration, while in the course of
> this iteration, a matrix-vector product occurs, with presumably a very
> (very) large matrix (since that's what iterative solvers do). So it is
> very likely that the iterations are dominated by the product anyway,
> unless the matrix is small, in which case a direct solver should be
> preferred. Bad, bad, bad... I promise I won't do that again.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message