Phil Steitz wrote:
[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.
I'm sure that serialization matured over many minor and major versions of Collections. So yes, we can gain knowledge from them on how to maintain it properly across versions in the future. I do not think the user will misinterpret our intentions and the capability of the implementation if we clearly state it compatibility across versions is not a guarantee or a requirement we wish to meet at this time with this version.
While I salute you for your excellent efforts in getting us closer to release. Is ever so clear to me now that we need to get versions out there so that we can get more user feedback on the features they want, this will help drive the direction of our inhouse development further and clarify if the necessity of any features we maintain. We are totally missing the "Release Early, Release Often" aspect of Open Source at this time. We need to be less "perfectionist" as a group about getting out this first release out the door, allot more are going to come after it. Its very important at this time that we get the cycle moving rather than push for the "absolute perfect release".
[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.
The "transient" keyword is used to block a field from being serialized, so for instance, if you blocked the internal Function from being serialized on serialization, then on deserialization it would not exist and the field would be forced to be null. At least in our current implementation, we can guarantee that our Functions will not be "null". Do we really want to shortchange the user by removing serialization when we can at least guarantee and show an example of how it is to be managed in our implementation.
Theres no way "anyone" could make the guarantee that a third party implementation of their interface is going to perform the way they expect. The user can only accomplish serialization if the entire object tree is serializable. If a third party hasn't taken such a consideration into order it is an issue between the third party and the user, not us.
[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.
Well, I think you got me on that point. We can't make these subclasses serializable as long they are inner classes or anonymous classes, and it is highly discouraged that they be made such according to the spec.
See the bottom of this page: http://babbage.clarku.edu/java/docs/guide/serialization/spec/serial-arch.doc10.html
But its important to note that all these anonymous classes extending ContinuedFraction are locally defined and only exist within the method call, theres no reason that these should need to be serializable given that case as they are temporary and no reference to them is maintained in the object tree. As such providing the Serializable interface is a courtesy to users who may want to make subclasses of ContinuedFraction which can be serialized.
[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
We definitely have very different perspectives on the subject. ;-)
The best argument I can give for the reason to maintain serialization on these classes that have very little internal state (like special functions) is that they "are" object instances and can exist in the object hierarchy being serialized. Its important to recognize that these end up being the "leaves" of the the object tree being serialized. As long as any class is instantiated as a non-singleton object in the api, I believe it should maintain at least the serialization interface. Imagine serializing a tree containing these objects and not being able to recover it simply because the developers didn't supply a serialization interface on an object referenced in the tree. Its then up to you to provide customization to support it, if the object is a private "leaf" somewhere deep in the implementation, this becomes almost impossible to accomplish, thus making the whole API limited. By stripping serialization from on class you've effectively handicapped the entire implementation to be unserializable.
I believe its important to provide at least the interface where ever possible in the api because of this. This is why I believe original email concerning Serialization is a Red Herring, it was an overly pessimistic viewpoint on serialization, the benefits of supplying even the most minimal of capability far outweigh any complications that occur. Providing the capability attracts users and developers who want to use it, who will give you good solid feedback on any deficiencies. Thats how you build a stable solid api, by listening to your users. We have no external users at this time because we have no release. We need a release, and I personally need it with these serialization features so we can attract the users and mature it. I will be one of those users/developers who will be here to help mature it, thus we already have some support in place for its maturation.
-- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
