[mark] I feel that you think that just because we happen to include the Serialization Interfaces to these classes, that somehow we have to guarantee that they are serializable across releases and the somehow we are stuck with the current implementation. I do not believe we are required to maintain such a claim at all. Having the Serialization interface gives only the most simplistic and default serialization behavior. We do not claim to be supporting serialization across versions and changes across versions are currently not required to meet any serialization compatibility to previous versions. [phil] I was assuming that we would be making the serialization compatability commitment across versions, similarly to what [collections] does (and maintains tests to ensure). I may be misinterpreting the [collections] test framework, however and / or generally accepted practice in j-c. Perhaps others can explain? I have been burned by serialization incompatability in the past; so my personal preference would be to avoid breaking it. [phil] >* Drop from all UnivariateRealSolvers. The API is not stable enough to be tied to >the physical implementation (there are lots of protected fields, including a >UnivariateRealFunction, which does not have to be serializable and I would be -1 to >forcing this). If kept, custom serialization needs to be added and it is not clear >to me how this should work.
[mark] If users are working with serialization, then they are probably working as well with their own (or the default provided) implementations of UnivariateRealFunction, as such they can assure their Functions are serializable. If they are working with third party implementations of UnivariateRealFunctions, then we make no guarantee serialization of such implementations. If we take this position, no customization is necessary. [phil] So we implement the interface, but don't guarantee that it will work? Unless we *require* UnivariateRealFunctions to implement Serializable (or make the function transient, which is awkward), serialization can fail. [phil] >* Drop from ContinuedFraction (no reason to serialize, burdens subclasses). > [mark] How does it burden subclasses? If they want to support Serialization they can, if they don't want to, then they don't. [phil] No, they have to support serialization. [phil] >* Either drop or customize serialization for all classes in the univariate package >(other than StatisticalSummaryValues), especially those in the moment subpackage. >Default serialization ties us to the current physical implementation, which may well >change as we optimize implementations. For example, SummaryStatisticsImpl currently >holds a (redundant) private field n. Removing this field after release would break >backward serialization compatability. I will probably eliminate this field before >release, but this is the kind of thing that makes me want to be conservative about >serialization. My vote would be to release 1.0 without serialization support for >these classes. [mark] Again, we establish the statement that we do not guarantee serialization as compatible across versions at this time. I need serialization capabilities in this implementation and I don't require it, or expect others who use the api the way I do (in Object Oriented Agent Based Java Simulation) to be at all concerned with Serialization across versions of the api. [mark] I understand you may have discomfort with this. But I think the original email that suggested this as an issue was entirely a "Red Herring". There are not significant drawbacks to including the Serialization interfaces with a simple notice that we do not guarantee consistent behavior across versions. I believe that if we provide event the simplest default behavior, then we will attract users willing to test out the capability and developers who are willing to help us support it further. If we do not, then you loose those users/developers interest. We are trying to create an API that is better than whats out there, serialization is already out there in api's like COLT and RngPack. [phil] Look carefully at what is serializable and what is not in COLT, for example. I do not think that it is good practice to implement serialization when there is no logical reason do do so (e.g special functions, continued fraction impls, etc.). I also need to hear from other commons committers that it is OK to ignore backward serialization compatability before releasing the classes mentioned above with default serialization. My opinion is that we should avoid this kind of thing. Phil
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
