----- Original Message -----
From: "sebb" <seb...@gmail.com>
To: "Commons Developers List" <dev@commons.apache.org>
Sent: Saturday, June 20, 2009 4:02 AM
Subject: Re: svn commit: r785552 - in
/commons/proper/math/trunk/src:java/org/apache/commons/math/complex/Complex.javasite/xdoc/changes.xml
On 20/06/2009, Bill Barker <billwbar...@verizon.net> wrote:
----- 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.
In which case, why not make Complex final?
Personally, I have no problem with making it final. But the existance of
createComplex seem to point to somebody having a use case to subclass it.
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 readResolve() method needs to be protected otherwise subclasses
will not use it.
I'm being dense here. I thought that ObjectInputStream ignored qualifiers
on this method.
The subclass could still subvert the Complex invariants by using the
overridable createComplex() method to return the deserialised Complex
instance without setting the transient fields correctly.
I think we'll either have to make the class final, or accept that
subclasses may be able to subvert it if they try hard enough.
Yes, but they have to try pretty hard ;). At least a half dozen methods
that use createComplex need to be overridden to have a working subclass.
But does that matter? There are probably other serializable math
classes that don't protect themselves.
IMHO, it doesn't matter that much.
> 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
---------------------------------------------------------------------
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
