Building and Running MegaMek under Classpath + Cacao CVS HEAD

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Kernel]     [Linux Cryptography]     [Fedora]     [Fedora Directory]     [Red Hat Development]

  Powered by Linux