You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@steitz.com> on 2004/05/23 18:27:17 UTC
[math][proposal] Drop serialization from selected classes
I would like to modify the following classes to make them no longer
implement Serializable. Any objections?
AbstractDescriptiveStatistics
BisectionSolver
BrentSolver
ChiSquareTestImpl
DefaultTransformer
DescriptiveStatistics
DescriptiveStatisticsImpl
DistributionFactoryImpl
Erf
Gamma
NewtonSolver
SecantSolver
SplineInterpolator
SummaryStatisticsImpl
TTestImpl
TransformerMap
UnivariateRealSolverFactoryImpl
UnivariateRealSolverImpl
ValueServer
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math][proposal] Drop serialization from selected classes
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Stephen Colebourne wrote:
>>The Math API maintains no "transient" fields. However, we do have
>>"private static" fields in many classes and it would eventually be wise
>>to verify these are or are not properly handled during the serialization
>>process. I've worked hard on the statistic packages and feel confident
>>that I've address the state of its static fields appropriately.
>
> To be clear, static fields are not stored in the serialized data, or altered
> when an instance is created from serialized data.
>
Yes, so what needs review is if an when a field is static, is it altered
at any time in any way. I know this doesn't happen at least in the stat
package. I'm not 100% sure concerning elsewhere, an code review on my
part should be relatively easy.
>
>>Serialization Id's are only necessary if you are going to have a
>>concern with serializing across versions of the math library and want to
>>be able to match similar classes in different versions. This is not
>>something that I see happening allot, usually when I am serializing, I
>>am deserializing using the same version of the library because my
>>application is installed on all machines I'm running the simulation on.
>
> As a reviewer, I would be content, not happy, if there was a clear statement
> that the serialized format may change between versions of the library.
> However, using an assigned serialVersionUID will greatly reduce the chance
> of breakages and let the JDKs design really work.
>
This is very true and would probably be the same amount of work as the
proposed removal of the Serialization Interfaces.
>
>>The benefit of letting the JVM generate the serialVersionUID's is that
>>you don't need to update them every time you change something in your
>>classes.
>
> AFAIN this is incorrect. Although the serialVersionUID is generated based on
> the methods and fields of the class it is in fact just a number. Simply
> declaring every serializableVersionUID with the id of 1 would also work.
>
Yes, I probably misspoke or wasn't very clear. It is sufficient to have
simply the Serialization interface to facilitate serialization. I agree
it is advantageous to maintain serialversionUID's to take full advantage
of the JVM. Though, for bare bones serialization within the same API
version and JVM, the autogeneration of serialversionUID's is available
and sufficient.
> The key point is that you never change the serialVersionUID once you have
> assigned it. The default tool simply provides a suitable number that is
> unlikely to be duplicated in another class.
>
Very true, Serialization UID's provide a means to identify appropriate
classes to deserialize to when attempting to deserialize across versions
of the API/JVM. If you anticipate requiring the (de)serialization of
checkpoints across both versions of the API and versions of the JVM,
then yes it is wise to maintain serialversionUID's.
> Thus, I would still encourage [math] to provide a serialVersionUID in every
> serializable class.
>
> Stephen
>
I'll be glad to go through the API and generate these where they are absent.
-Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math][proposal] Drop serialization from selected classes
Posted by Stephen Colebourne <sc...@btopenworld.com>.
> The Math API maintains no "transient" fields. However, we do have
> "private static" fields in many classes and it would eventually be wise
> to verify these are or are not properly handled during the serialization
> process. I've worked hard on the statistic packages and feel confident
> that I've address the state of its static fields appropriately.
To be clear, static fields are not stored in the serialized data, or altered
when an instance is created from serialized data.
> Serialization Id's are only necessary if you are going to have a
> concern with serializing across versions of the math library and want to
> be able to match similar classes in different versions. This is not
> something that I see happening allot, usually when I am serializing, I
> am deserializing using the same version of the library because my
> application is installed on all machines I'm running the simulation on.
As a reviewer, I would be content, not happy, if there was a clear statement
that the serialized format may change between versions of the library.
However, using an assigned serialVersionUID will greatly reduce the chance
of breakages and let the JDKs design really work.
> The benefit of letting the JVM generate the serialVersionUID's is that
> you don't need to update them every time you change something in your
> classes.
AFAIN this is incorrect. Although the serialVersionUID is generated based on
the methods and fields of the class it is in fact just a number. Simply
declaring every serializableVersionUID with the id of 1 would also work.
The key point is that you never change the serialVersionUID once you have
assigned it. The default tool simply provides a suitable number that is
unlikely to be duplicated in another class.
Thus, I would still encourage [math] to provide a serialVersionUID in every
serializable class.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math][proposal] Drop serialization from selected classes
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
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
Re: [math][proposal] Drop serialization from selected classes
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
After reviewing EmpiricalDistributionImpl, its clear to me now it
doesn't require any customized serialization as it doesn't maintain an
open file connection outside of its methods. However, ValueServer does,
I would like to add an "index" refering to how far into the replay
stream it has gotten, this was we can reopen and cursor to that point
when it its deserialized. This should be all thats required to assure
that replaying can be restarted, however, if its deserialized on a
platform where the replay file is not retrievable, then this will and
should fail appropriately.
-Mark
Mark R. Diggory wrote:
> Just to give an update, I generated serialversionUID's for all the
> current Serializable classes in the src/java directory for which they
> were absent. I'm just waiting on our clarifying the decision prior
> committing everything. I am currently working on a serialization
> solution for the ValueServer/EmpiricalDistribution classes.
>
> -Mark
>
> p.s. If anyone is curious
>
> Mark R. Diggory wrote:
>
>> 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: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>
>
>------------------------------------------------------------------------
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
Re: [math][proposal] Drop serialization from selected classes
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Just to give an update, I generated serialversionUID's for all the
current Serializable classes in the src/java directory for which they
were absent. I'm just waiting on our clarifying the decision prior
committing everything. I am currently working on a serialization
solution for the ValueServer/EmpiricalDistribution classes.
-Mark
p.s. If anyone is curious
Mark R. Diggory wrote:
> 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: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
Re: [math][proposal] Drop serialization from selected classes
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
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
Re: [math][proposal] Drop serialization from selected classes
Posted by Phil Steitz <ph...@steitz.com>.
Mark R. Diggory wrote:
> These are all used either in stats or tests of stats.
>
> >>> AbstractDescriptiveStatistics
Should not have been on the list, not currently Serializable and as an
abstract factory, makes no sense to serialize.
> >>> DefaultTransformer
> >>> DescriptiveStatistics
Also a factory, why serialize?
> >>> DescriptiveStatisticsImpl
> >>> SummaryStatisticsImpl
> >>> TransformerMap
>
> But, like Stephen pointed out, I'd recommend adding serialversionUID's
> over removing Serialization Interfaces across the entire math package.
>
> I've written simplified serialization/deserialization test support into
> the TestUtils. As such, its very easy to write tests that simply call
> this method, then test if all the values are still correct in the Object
> returned.
>
> http://jakarta.apache.org/commons/math/xref-test/org/apache/commons/math/TestUtils.html#71
>
The point is not so much just testing, but also the backward compatability
issues and extra burden when extending. 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.
BisectionSolver
BrentSolver
ChiSquareTestImpl
DistributionFactoryImpl
Erf
Gamma
NewtonSolver
SecantSolver
SplineInterpolator
TTestImpl
TransformerMap
UnivariateRealSolverFactoryImpl
UnivariateRealSolverImpl
ValueServer
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math][proposal] Drop serialization from selected classes
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
These are all used either in stats or tests of stats.
>>> AbstractDescriptiveStatistics
>>> DefaultTransformer
>>> DescriptiveStatistics
>>> DescriptiveStatisticsImpl
>>> SummaryStatisticsImpl
>>> TransformerMap
But, like Stephen pointed out, I'd recommend adding serialversionUID's
over removing Serialization Interfaces across the entire math package.
I've written simplified serialization/deserialization test support into
the TestUtils. As such, its very easy to write tests that simply call
this method, then test if all the values are still correct in the Object
returned.
http://jakarta.apache.org/commons/math/xref-test/org/apache/commons/math/TestUtils.html#71
-Mark
Phil Steitz wrote:
> Mark R. Diggory wrote:
>
>> I see great value in maintaining and improving functionality such
>> as this. I do not think that it is something that should limit us from
>> releasing. It is a secondary characteristic that does not impact
>> currently existing performance outside of serialization. I also think
>> removing it sets us back in terms of its development. If it is a
>> sensitive subject, we can suggest via disclaimer that it is under
>> development in various areas of the API at this time and usage is not
>> fully tested.
>>
>> If your looking for examples where it is used. I'm currently using
>> them with Simulations using RePast and Mason. Mason allows checkpointing
>> the simulations to serialized files and then deserializing and
>> restarting them. This allows for both "distributed simulation" and for
>> persistence of state. Being able to checkpoint the stat classes is
>> critical in my applications.
>
>
> Can you please specify which of the classes listed in the [proposal]
> need serialization support? I omitted most of the stats objects from
> the list.
>
>>
>
> Phil
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math][proposal] Drop serialization from selected classes
Posted by Phil Steitz <ph...@steitz.com>.
Mark R. Diggory wrote:
> I see great value in maintaining and improving functionality such
> as this. I do not think that it is something that should limit us from
> releasing. It is a secondary characteristic that does not impact
> currently existing performance outside of serialization. I also think
> removing it sets us back in terms of its development. If it is a
> sensitive subject, we can suggest via disclaimer that it is under
> development in various areas of the API at this time and usage is not
> fully tested.
>
> If your looking for examples where it is used. I'm currently using
> them with Simulations using RePast and Mason. Mason allows checkpointing
> the simulations to serialized files and then deserializing and
> restarting them. This allows for both "distributed simulation" and for
> persistence of state. Being able to checkpoint the stat classes is
> critical in my applications.
Can you please specify which of the classes listed in the [proposal] need
serialization support? I omitted most of the stats objects from the list.
>
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math][proposal] Drop serialization from selected classes
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
I see great value in maintaining and improving functionality such
as this. I do not think that it is something that should limit us from
releasing. It is a secondary characteristic that does not impact
currently existing performance outside of serialization. I also think
removing it sets us back in terms of its development. If it is a
sensitive subject, we can suggest via disclaimer that it is under
development in various areas of the API at this time and usage is not
fully tested.
If your looking for examples where it is used. I'm currently using
them with Simulations using RePast and Mason. Mason allows checkpointing
the simulations to serialized files and then deserializing and
restarting them. This allows for both "distributed simulation" and for
persistence of state. Being able to checkpoint the stat classes is
critical in my applications.
I never fully addressed his email issues. So I will start to do so now:
Stephen Colebourne wrote:
> 2) Wherever there is implements Serializable you should have a
> serialVersionUID static field. And are you confident that the
> implementations are well enough established to allow for
> serialization?
I use it now on a regular basis with the stat package.
Stephen Colebourne wrote:
> What about transient fields? Serialization is definitely not about
> adding the implements clause to everything.
From Sun Tutorial:
> Several techniques are available to protect sensitive data in
> classes. The easiest is to mark fields that contain sensitive data as
> private transient. transient and static fields are not serialized or
> deserialized. Marking the field will prevent the state from
> appearing in the stream and from being restored during
> deserialization. Since writing and reading (of private fields) cannot
> be superseded outside of the class, the class's transient fields are
> safe.
The Math API maintains no "transient" fields. However, we do have
"private static" fields in many classes and it would eventually be wise
to verify these are or are not properly handled during the serialization
process. I've worked hard on the statistic packages and feel confident
that I've address the state of its static fields appropriately.
Serialization Id's are only necessary if you are going to have a
concern with serializing across versions of the math library and want to
be able to match similar classes in different versions. This is not
something that I see happening allot, usually when I am serializing, I
am deserializing using the same version of the library because my
application is installed on all machines I'm running the simulation on.
The cost of automated calculation of serialVersionUID's is small, "one
time" at JVM startup and cached.
The benefit of letting the JVM generate the serialVersionUID's is that
you don't need to update them every time you change something in your
classes. I have generated for many of the stat classes I've been working
on. If it really arose that this was an issue (issue brought up by user)
I would gladly take on the responsibility and address it by generating
and maintaining serialversionUID's for the rest of the classes in the
project.
Myths about Serialization performance:
http://www.javaworld.com/javaworld/javaqa/2003-06/02-qa-0627-mythser.html
An excellent article with performance timings and examples of using
serialization to accomplish cloning:
http://www.javaworld.com/javaworld/javaqa/2003-01/02-qa-0124-clone.html
Sun Tutorial on Serialization:
http://java.sun.com/docs/books/tutorial/essential/io/providing.html
-Mark
Phil Steitz wrote:
> Mark R. Diggory wrote:
>
>> I'm not sure why your want to do this? We've already put a great
>> deal of effort into assuring its possible and consistent.
>>
>> I would like to see as much serialization maintained as possible.
>> Being able to serialize/deserialized these objects is a powerful
>> feature. I've worked hard to show that this serialization is
>> functional and error free with the tests that I have written (at
>> least in the statistics package).
>
>
> Cf. Stephen's remarks on serialization in the API review. Unless
> there is a compelling reason for these classes to be serializable, I
> would prefer not to force ourselves (and anyone subclassing these
> things) to maintain support and worry about serialization
> compatability. Can you explain why these classes (many of which have
> no state) *should* be serializable?
>
>>
>>
>> -Mark
>>
>>
>> Phil Steitz wrote:
>>
>>> I would like to modify the following classes to make them no
>>> longer implement Serializable. Any objections?
>>>
>>> AbstractDescriptiveStatistics BisectionSolver BrentSolver
>>> ChiSquareTestImpl DefaultTransformer DescriptiveStatistics
>>> DescriptiveStatisticsImpl DistributionFactoryImpl Erf Gamma
>>> NewtonSolver SecantSolver SplineInterpolator
>>> SummaryStatisticsImpl TTestImpl TransformerMap
>>> UnivariateRealSolverFactoryImpl UnivariateRealSolverImpl
>>> ValueServer
>>>
>>> Phil
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> commons-dev-unsubscribe@jakarta.apache.org For additional
>>> commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math][proposal] Drop serialization from selected classes
Posted by Phil Steitz <ph...@steitz.com>.
Mark R. Diggory wrote:
> I'm not sure why your want to do this? We've already put a great deal of
> effort into assuring its possible and consistent.
>
> I would like to see as much serialization maintained as possible. Being
> able to serialize/deserialized these objects is a powerful feature. I've
> worked hard to show that this serialization is functional and error free
> with the tests that I have written (at least in the statistics package).
Cf. Stephen's remarks on serialization in the API review. Unless there is
a compelling reason for these classes to be serializable, I would prefer
not to force ourselves (and anyone subclassing these things) to maintain
support and worry about serialization compatability. Can you explain why
these classes (many of which have no state) *should* be serializable?
>
>
> -Mark
>
>
> Phil Steitz wrote:
>
>> I would like to modify the following classes to make them no longer
>> implement Serializable. Any objections?
>>
>> AbstractDescriptiveStatistics
>> BisectionSolver
>> BrentSolver
>> ChiSquareTestImpl
>> DefaultTransformer
>> DescriptiveStatistics
>> DescriptiveStatisticsImpl
>> DistributionFactoryImpl
>> Erf
>> Gamma
>> NewtonSolver
>> SecantSolver
>> SplineInterpolator
>> SummaryStatisticsImpl
>> TTestImpl
>> TransformerMap
>> UnivariateRealSolverFactoryImpl
>> UnivariateRealSolverImpl
>> ValueServer
>>
>> Phil
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math][proposal] Drop serialization from selected classes
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
I'm not sure why your want to do this? We've already put a great deal of
effort into assuring its possible and consistent.
I would like to see as much serialization maintained as possible. Being
able to serialize/deserialized these objects is a powerful feature. I've
worked hard to show that this serialization is functional and error free
with the tests that I have written (at least in the statistics package).
-Mark
Phil Steitz wrote:
> I would like to modify the following classes to make them no longer
> implement Serializable. Any objections?
>
> AbstractDescriptiveStatistics
> BisectionSolver
> BrentSolver
> ChiSquareTestImpl
> DefaultTransformer
> DescriptiveStatistics
> DescriptiveStatisticsImpl
> DistributionFactoryImpl
> Erf
> Gamma
> NewtonSolver
> SecantSolver
> SplineInterpolator
> SummaryStatisticsImpl
> TTestImpl
> TransformerMap
> UnivariateRealSolverFactoryImpl
> UnivariateRealSolverImpl
> ValueServer
>
> Phil
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org