commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: svn commit: r785552 - in /commons/proper/math/trunk/src: java/org/apache/commons/math/complex/Complex.java site/xdoc/changes.xml
Date Fri, 19 Jun 2009 12:47:20 GMT
luc.maisonobe@free.fr wrote:
> ----- "sebb" <sebbaz@gmail.com> a écrit :
>
>   
>> 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);
>> }
>>     
>
> 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-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
>
>   


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


Mime
View raw message