commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <>
Subject Re: [math][proposal] Drop serialization from selected classes
Date Mon, 24 May 2004 16:46:21 GMT
Phil Steitz wrote:

> The point is not so much just testing, 

I'm just showing that effort has been put into making this a testable 
feature of our packages.

> but also the backward compatability  issues and extra burden when 
> extending.  

I'm not convinced there is an extra burden. If a user wants to assure 
they can serialize a class that extends something in our library, its 
actually less of a burden for them if we can show the library supports 
it. If the users don't use serialization, then they are under no burden 
to assure its applicable to their objects and there is no impact to them.

The real burden is that users who actually want to use serialization 
will not use our library because we arn't supporting it. Fewer users = 
Less feedback.

> If you feel that the classes above must implement Serializable, then 
> yes, please generate and add the serialization IDs where they are 
> missing.  Can I assume that there are no objections to removing 
> serialization from the classes below?  If so, please provide a reason 
> that the class should implenment Serializable.
It behoves us to look over these classes as well and determine if there 
are any restictions to their being serializable. The restictions I would 
apply are the following

1.) If I can see is if there is a static object that is altered by any 
2.) If any FileInput/OutputStream or file handle is maintained in field 
outside of a method.
3.) If any threading is used.
4.) If underlying Collections exists with questionable objects.

org.apache.commons.math.analysis - none
org.apache.commons.math.complex - none
org.apache.commons.math.distributions - none
org.apache.commons.math.linear - none
org.apache.commons.math.random  -  Yes, ValueServer maintains files and 
streams. Solution mark these as transient and use 
serialization/deserialization methods to maintain state. 
EmpiricalDistribution uses an ArrayList of generic objects
org.apache.commons.math.special - none
org.apache.commons.math.stat - Yes Frequency has an underlying 
collection of generic objects.
org.apache.commons.math.stat.inference - none
org.apache.commons.math.stat.multivariate - none
org.apache.commons.math.stat.univariate - none
org.apache.commons.math.util - TransformerMap maintains an underlying 
Map of custom or provided transformer objects

So based on this review we have one case where serialization requires 
some small customization in "random" and three cases where its the users 
responsibility to maintain that the objects they wish to serialize are 
infact, serializable. In all these cases serialization will throw an 
exception stating that there are objects that cannot be serialized, 
which would be the proper response alerting the user that their objects 
are not properly serializable.

I'm still convinced that Serialization can be maintained across the 
entire project with one minor customization to manage the case in 

As I use this feature, have written tests for it, and understand the 
requirements for its inclusion. I would like to make an effort to 
support this further. I would like to take on the task of writing tests 
for serialization across the entire project, including serialization 
UID's and maintaining any existing serialization interfaces. Tests for 
serialization can be simply copies of existing tests with calls to the 
TestUtils serialization method in between, comparing the serialized to 
unserialized result for the objects.


View raw message