luc.maison...@free.fr wrote:
----- "sebb" <seb...@gmail.com> a écrit :
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);
}
I like this!
Luc
+1
Phil
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.
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
