----- "sebb" <seb...@gmail.com> a écrit :
> On 19/06/2009, Phil Steitz <phil.ste...@gmail.com> wrote:
> > luc.maison...@free.fr wrote:
> >
> > > ----- "Bill Barker" <billwbar...@verizon.net> a écrit :
> > >
> > >
> > >
> > > > ----- Original Message ----- From: <luc.maison...@free.fr>
> > > > To: "Commons Developers List" <dev@commons.apache.org>
> > > > 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" <phil.ste...@gmail.com> 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:
> > 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
> > >
> > >
> > >
> >
> >
> >
> ---------------------------------------------------------------------
> > 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
