First, thanks for continuing to respond, I do want to understand the reasoning behind this decision and you are helping make it clear.
We are already in trouble, because of this lack of policy, for several classes for which "Serializable" is a supposedly innocuous feature (e.g. fields that should be transient cannot be because no explicit serialization is implemented).
Do you mean that if you corrected this and made them transient, you would introduce an incompatibility with objects serialized using older versions of the class? If not that, then could you explain?
In the Commons project, there is a commitment that minor releases must be fully compatible; that implies that relying on a default serialization would prevent any change to internal structure of a class.
I understand completely about not making changes in minor releases. Since that commitment is for minor releases, that implies that it could be done at the next major release, right?
Maybe that you are not aware of the constraints imposed by "Serializable"; maybe that you don't care because in your use-case, you'll never be confronted to the problem of a wrong serialized form. But another user's use-case might bring him here complaining about our inconsistent support of "Serializable". Would he be less right than you?
"Not aware" is more likely than "don't care". I may be ignorant but I'm not callous. I understand that suddenly changing how a class is serialized could break things for use cases other than mine and that is no less right than mine. Another reason to restrict the change to a major version.
It is always trivial to add "implements Serializable" to a class definition. But it is not trivial to do the implementation in the right way; just adding "implements Serializable" is not the right way, never. Again, it could be good enough for some purpose, but the wish for CM to be an example of good Java programming, is not compatible with statements such as "We know it's sloppy, so don't use it whenever you need something that works...".
This is the core of the issue. I can see that implementing Serializable might require special code in some cases, but why is just adding "implements Serializable" never the right way? You provided an example of wrapper code to do serialization for a class that is not serializable, but would you provide an example of how to transform a class that is not serializable directly into one that is? I.e., not with a wrapper, but by adding "implements Serializable" and then adding the explicit serialization methods to the class itself? I would like to see an example of "good Java programming" with regard to serialization.
The purpose of CM is to provide robust implementations of mathematical utilities; supporting distributed applications is a totally different game.
In my business, we often do massive calculations that require hundreds or thousands of cpu-hours that need to be completed overnight, so they need to be distributed. Regardless of how robust the implementation is otherwise, if it does not support distribution, then that alone might make it unusable.