On 3/2/06, Thomas Fitzsimmons <fitzsim@xxxxxxxxxx> wrote: > On Thu, 2006-03-02 at 00:06 -0500, James Damour wrote: > > > I also looked into the compatability between MegaMek clients and servers > > running on proprietary and free VMs. There was an initial hiccup where > > I was getting incompatable serialVersionUID, but I quickly realized that > > the problem was caused by my compiling MegaMek twice, once with Sun > > tools, and once with Free tools. When I gave both VMs the same set of > > classes (or JAR file), they could connect without difficulty. > > Isn't this the point of serialVersionUID though? If someone builds and > runs MegaMek with Sun's tools and another person builds and runs MegaMek > with free tools, the two MegaMek instances should be able to serialize > and unserialize each other's data. Where this isn't the case don't we > need to update our serialVersionUID fields? I read that as svuids of MegaMek-specific classes... in fact I think it *must* have meant MegaMek-specific classes, because you *can't* build Classpath itself with Sun's tools. So the issue reduces to the known one of "the svuid algorithm is only well-specified for a given *compiled* class, not for a given java source file" (which is why some compilers warn about Serializable classes without explicit svuids). The right solution is to add svuids to the classes within MegaMek. Stuart. -- http://sab39.dev.netreach.com/
