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]
