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?
> 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.
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.
But does that matter? There are probably other serializable math
classes that don't protect themselves.
>
>
> > 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
