Hi. > >> > > >> > > > >> > > * org.apache.commons.math3.linear.SymmLQ: Yet another problem with a > >> > > probably unnecessary "Serializable"... > >> > > > >> > In fact, it comes from a nested class which extends EventObject, so it > >> > must be (unfortunately) serializable. I'll look into it. > >> > >> Then, it seems that you can define it as "static", and it will make > >> FindBugs > >> happy, I think. [The problem is that it is a "plain" inner class, in a > >> non-serializable class.] > >> > > > > I've performed this change and also had to make the "state" field > > "transient" because "State" is not "Serializable" and it cannot be > > since "RealLinearOperator" is not "Serializable" and cannot be (IIUC).[1] > > [At first sight, all this confirms that we should stay away from > > "Serializable". :-}] > > > > I do agree with you on this, although my point of view is far less > enlightened than yours. I know "serializable" is difficult, > problematic and error-prone, so I just keep away from it as a general > rule. I should therefore apologize for having carelessly implemented > serializable in this particular instance.
I don't know whether I am enlightened :-). Maybe just lazy, as in not wanting to put more burden than necessary on a too small development team... > > [...] > > > > Actually, I *do* want to handle it differently (I've even set a TODO > tag in the source). In short, I've used references a lot in order to > avoid creating new objects, but this makes event handling a bit > intricate, and I want to refactor that part (keeping the public API > unchanged). Yes, that does not look too clean. ;-) Best, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
