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 method.
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 ValueServer.
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.
-Mark
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
