🚀 go-pugleaf

We are seeing a problem trying to serialize and send objects over HTTP,
however, I suspect it is a serialization problem and would affect RMI
also. The problem is the sensitivity of the serialization versioning
mechanism. It is intended to ensure class consistency at the serialize
and deserialize ends of some object transfer. The problem is, the
generated serialVersionUID numbers seem to be affected by the JVM
actually
used. We are using a 1.2 HTTP server and 1.1.6 Client which each create
different serialVersionUIDs so an InvalidClassException is thrown and
the
object is not succesfully sent. When we use the same JVM version (1.1.6)
on the client and server ends, things work fine. We were also able to
get
the transfer to work by explicitly setting the class serialVersionUID
field for our custom classes, but, we do not have that option for
standard core or 3rd party Java classes. 

This would seem to be a rather large problem that would restrict
serialization any time the client and server JVMs are even slightly
mismatched. Is there some general way to deal with this problem or are
we
missing something?

                Thanks,
                  Gary Whitten
                  whitteng@con2inc.com