----- Original Message -----
From: "sebb" <seb...@gmail.com>
To: "Commons Developers List" <dev@commons.apache.org>
Sent: Friday, June 19, 2009 5:14 AM
Subject: Re: svn commit: r785552 - in
/commons/proper/math/trunk/src:java/org/apache/commons/math/complex/Complex.java
site/xdoc/changes.xml
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);
}
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.
It is about as useful to subclass Complex as it is to subclass Double. But
with my recent patch, where the Complex readResolve method is final, but
invokes a method than can be overridden in a subclass (but which must still
return a Complex instance), I think that most of the problems would be
solved. As always, comments welcome.
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
