RE: [Orekit Developers] Is serialization of propagators really useful

[Tanguy Yannick <Yannick.Tanguy@cnes.fr>]

>Hi all,
>
Hi Luc,

> From the very beginning of Orekit (back in 2002), some basic priciples have been applied throughout the library. [..] Since this change, when a numerical propagator was serialized and deserialized, the new propagator had no integrator anymore. So the user was required to reset a new integrator using the new setIntegrator method. This was not really satisfying.
>
>We are now facing worse problems as there are more places were objects cannot really be serialized. As an example, force models may require a celestial body such as the Sun, which is provided as a PVCoordinatesProvider, which is not serializable. Even if the providers available in Orekit such as CelestialBody could be serialized, it would be a very bad idea to do so as they can have huge datasets.
>

I agree that some objects don't need to be serialised. 

>There were several (heated) discussions about serialization a while ago in the Apache Commons Math (see <http://markmail.org/thread/26zmab5xo2rr4eap> for the last one). The outcome was that basically serialization must not be a general rule and should be done properly and one a case by case basis. One of the interesting outcome of these discussions is a trick that allows users of a non-serializable class to still use serialization in their top level class as they requires it using proxy objects to replace the non-serializable ones (the use can be because they have a non-serializable field in their class or the extend a non-serializable class). This is used in Apache Commons Math at a few places (see for example PointValuePair, which is a case where the serializable class extends a non-serializable one). We also have started using this trick in Orekit as well (see for example the DataTransferObject inner class in the InterpolatingTransformProvider class in the frames package).
>
>So our basic principle about serialization is difficult to manage, and thanks to the proxy objects trick it is in fact not really needed anymore. I would propose to follow Apache Commons Math policy and limit our use of Serializable to some basic classes where it makes sense (typically data containers like orbit, attitude, date, transforms, body shapes, geodetic point ...) and remove it for complex cases like Propagator or AttitudeProvider.
>What do you think about this change?

I agree with this principle, because serialisation may cause a lot of difficulties for complex objects with some algorithm (propagator, attitude provider, force models, event detectors,..). The use of Serializable for only the small data containers seems a good idea.

best regards,

Yannick

>best regards,
>Luc