----- "sebb" <[email protected]> a écrit : > On 19/06/2009, Phil Steitz <[email protected]> wrote: > > [email protected] wrote: > > > > > ----- "Bill Barker" <[email protected]> a écrit : > > > > > > > > > > > > > ----- Original Message ----- From: <[email protected]> > > > > To: "Commons Developers List" <[email protected]> > > > > Sent: Wednesday, June 17, 2009 2:58 PM > > > > Subject: Re: svn commit: r785552 - in > > /commons/proper/math/trunk/src: > > > > > > > > java/org/apache/commons/math/complex/Complex.java > > > > site/xdoc/changes.xml > > > > > > > > > > > > > > > > > > > > > > > > > ----- "Phil Steitz" <[email protected]> a écrit : > > > > > > > > > > > > > > > > > > > > > Sorry if I am being dense here. What serialization problem > do the > > > > > > > > > > > > > > > > > > > > > new > > > > > > > > > > > > > > > > > > > fields cause, exactly? The class is immutable and they are > set by > > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > constructor. > > > > > > > > > > > > > > > > > It takes more space to store. If someone uses serialization to > store > > > > > > > > > > > > > > or > > > > > > > > > send a bunch of complex >this will vastly increase the load. > > > > > > > > > > > > > > The main problem is that the fields can be either transient or > final, > > > > but not both (or rather, you can't reset the value of final > fields in > > readObject). I have a slight preference for transient for the > reason > > > > Luc gave (a BlockFieldMatrix<ComplexField> will get large > quickly), and > > > > have no problem doing the change myself. But I can wait for > other > > opinions. > > > > > > > > > > +1 for that. > > > You can reset final fields in readObject, with some > java.lang.reflect > > dirty tricks. Look at the DeserializeReal{Vector, Matrix} methods > in > > MatrixUtils. > > > > > > > > +1 > > Complex is not currently a final class, but if there are no use-cases > for it to be extended it could be made so, and one could then use the > "defensive readResolve" idiom (Effective Java item 57): > > private Object readResolve(){ > return new Complex(real, imaginary); > }
I like this! Luc > > This would still work even if Complex remained non-final, however > sub-classes could potentially subvert the deserialisation by > overriding the readResolve. Maybe that is a proce worth paying. > > The above code might be slightly slower than using reflection (or > maybe not), but it will always work regardless of security managers. > > > Phil > > > > > > > Luc > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: > > [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: > > [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
