Triggered by #234.
For better or worse, PyObject is Serializable, but serializations are unnecessarily incompatible accross Jython versions because there are no explicit serialVersionID fields. (See https://apidia.net/java/OpenJDK/25/?pck=java.io&cls=.Serializable for the background of this field)
This should be improved to make the usecase from #234 more stable, but also on its own right.
Automatic serialVersionIDs may change due to method reordering or all sorts of modifications that do not actually introduce a serialization incompatibility. Still, in those cases object deserialization is broken. When choosing version values, we can assign them such that compatibility to one previous Jython release is retained.
By the method explained in https://stackoverflow.com/questions/22169268/is-it-possible-to-get-serialversionuid-of-the-java-class-in-runtime it is possible to retrieve e.g. the ids for Jython 2.7.4 and then pin them for future versions in 2.7.5 onward.
What makes this a bit tedious is that it's not enough to do this for PyObject, but it has to be done for every subclass on its own. (Some script will get all version ids automatically.)
Still, I think it's crucial to fix this ASAP (i.e. for 2.7.5) to avoid further divergence.
Since 2.7.4 there have not been many changes, so pinning the versions should work. We can check for which classes versions do actually differ and examine those cases more closely.

Still have to think about derived classes, since they are generated. Perhaps it's best to let them be. We would have to touch the generator in a non-trivial way. Since they haven't been re-generated in a long while, maybe their serial versions did not even change for ages. (Unless changes in the parent class trigger a version change for subclasses.)

It would already be a win to pin the versions for the main builtin types like PyString, PyInt, PyList, ... since they are used most heavily. They are also the typical data types for serialization.

Ideas? Opinions?