🚀 go-pugleaf

I had a few pages discussing possible work around solutions
to this in my book, Programming Mobile Objects with Java,
but the bottom line is planning and design.  You have to think
ahead and plan on ways to extend your classes that are
compatible with Serialization.

                            - Jeff
--
Check out the Design Patterns archive!
http://www.DistributedObjects.com

I'm looking for Java contract positions.  Email
jobs @
 DistributedObjects 
   . com



Gary Whitten wrote:

> 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