commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <billwbar...@verizon.net>
Subject Re: svn commit: r785552 - in /commons/proper/math/trunk/src:java/org/apache/commons/math/complex/Complex.java site/xdoc/changes.xml
Date Sat, 20 Jun 2009 03:33:21 GMT

----- Original Message ----- 
From: "sebb" <sebbaz@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.steitz@gmail.com> wrote:
> luc.maisonobe@free.fr wrote:
>
> > ----- "Bill Barker" <billwbarker@verizon.net> a écrit :
> >
> >
> >
> > > ----- Original Message ----- From: <luc.maisonobe@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.steitz@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-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message