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, Luc > > 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-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
