Hi, On Thu, 2006-03-02 at 00:06 -0500, James Damour wrote: > Lillian Angel has done a truely remarkable job squashing rendering > problems, so what once looked like [1] now looks like [2]. I have > therefore built CVS HEAD of Classpath and Cacao in my Debian Sid chroot, > changed MegaMek "stable" (the "-r rel-0-30-0" branch) to use reflection > instead of a compile-time dependancy on sun.audio.* classes, and built > MegaMek.
I'm looking at reviving the mkcollections script so that you can replace collections.jar with a free replacement. > > There are still a few little bugs (which appear to depend on one's > operating environment:-( ). I'll be writing up Bugzilla reports over > the next few days/weeks to help run down the last few problems. Great, thanks. > > 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? Tom
