commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From S├ębastien Brisard <sebastien.bris...@m4x.org>
Subject [math] Does this break the API?
Date Fri, 09 Mar 2012 07:14:49 GMT
Dear all,
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?

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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message