Hi, On Thu, 2006-03-02 at 12:05 -0500, Thomas Fitzsimmons wrote: > 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]. > > [...] > > 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. Yes thanks for your support! It looks like MegaMek is actually playable now on our free stack. I look forward to it being bundled with the different distributions. Although I am afraid what it will do to the productivity of our hackers :) > > 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? Yes, and if we did our homework right then this is the case. See also our hacking guide http://www.gnu.org/software/classpath/docs/hacking.html#SEC19 > If a class has a field (of any accessibility) named serialVersionUID > of type long, that is what serialver uses. Otherwise it computes a > value using some sort of hash function on the names of all method > signatures in the .class file. The fact that different compilers > create different synthetic method signatures, such as access$0() if an > inner class needs access to a private member of an enclosing class, > make it impossible for two distinct compilers to reliably generate the > same serial #, because their .class files differ. However, once you > have a .class file, its serial # is unique, and the computation will > give the same result no matter what platform you execute on. But unfortunately that also needs to be done for the application code if it wants to be serializable between versions compiled with different tools. The best design for code you want to have Serializable is to think (and document!) the serialized form/fields and how the different methods interact with possible future extensions (through readObject() and writeObject() if necessary) and then add a fixed serialVersionUID to the class (if you already have deployed code compiled with a particular toolset then you should adopt the serialver number of this deployed version). Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://developer.classpath.org/pipermail/classpath/attachments/20060303/4b3d1b45/attachment.pgp
