Phil,
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.
The shortfall in removing serialization interfaces is that even just to support the simplest serialization of these objects, the user is required to write tons of code to implement the serialization of our classes, all because we didn't afford the courtesy of simply just supplying the serialization interface in the implementation.
You have to remember that the Serialiable interface is only a marker that allows the serialization facility in the JVM identify if serialization should occur to the object. The size difference between having the interface versus not isn't significant (NewtonSolver2 not serializable, NewtonSolver is serializable).
-rw-r--r-- 1 mdiggory tomcat4 1848 Jul 12 21:57 NewtonSolver2.class -rw-r--r-- 1 mdiggory tomcat4 1873 Jul 12 21:57 NewtonSolver.class
Phil Steitz wrote:
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.I would like to drop / modify serialization for the following:
* 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.
How does it burden subclasses? If they want to support Serialization they can, if they don't want to, then they don't.* Drop from ContinuedFraction (no reason to serialize, burdens subclasses).
As non static instance objects, theres a chance attempts will be made to serialize these in the object tree.* Drop from special functions, add argumentless constructors so subclasses can implement if desired (I see no reason to serialize these).
* Drop from ValueServer (needs custom serialization, not worth the effort).
I thought we had removed it until someone writes a custom implementation.
* 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.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.
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. I think this a very important feature to maintain.Sorry to sound like a broken record on this; but I am just not comfortable releasing the above classes with default serialization.
Phil
-Mark
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
