Re: Building and Running MegaMek under Classpath + Cacao CVS HEAD
On Fri, 2006-03-03 at 10:46 +0100, Mark Wielaard wrote: 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 *may* inspire them to want to implement v1.5 APIs so that they can use all the cool new features in the development branch of MegaMek! :) 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 I apologize for being unclear. The hiccup was indeed caused by MegaMek classes missing serialVersionUID fields. I have fixed this problem and submitted it to CVS. I have also added the files, .classpath and .project that Thomas Fitzsimmons sent me so that CVS checkouts withing Eclipse will automatically be built. I do not run Eclipse, so I can not directly confirm that these files work correctly, and I refer all problems with them to Thomas. -- James Damour (Suvarov454) [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Building and Running MegaMek under Classpath + Cacao CVS HEAD
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/ signature.asc Description: This is a digitally signed message part
Re: Building and Running MegaMek under Classpath + Cacao CVS HEAD
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
Re: Building and Running MegaMek under Classpath + Cacao CVS HEAD
On 3/2/06, Thomas Fitzsimmons [EMAIL PROTECTED] 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/
Building and Running MegaMek under Classpath + Cacao CVS HEAD
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. 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. 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. [1] http://www.damour.info/gallery/megamek/MegaMek-Kaffe-map_editor.jpeg [2] http://www.damour.info/gallery/megamek/MegaMek-Cacao-4-movement.png signature.asc Description: This is a digitally signed message part
