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: 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.
Well, Effective Java says otherwise, which is where I got the info.
Does OIS ignore the qualifier if the method is in a super-class?
What if the sub-class needs to call super.readResolve() ?
>
> > 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.
>
It's easy enough to subvert createComplex() for the readResolve() case
- "return this" - which won't set the transient fields.
If one can detect the calling method, the overriding createComplex()
could check for readResolve() as the immediate caller and only return
a corrupted instance in that case.
> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
