I think I found a bug in the serialisation/deserialisation of objects
that inherit from an abstract class.

Please have a look at the following testcase:

File test10/Element.java:
package test10;

import java.util.*;

abstract class Element {
    private Set set = new TreeSet();

    public void add(String t) {
	System.out.println("act1");
	set.add(t);
	System.out.println("act2");
    }
}


File test10/ConcreteElement.java:
package test10;

import java.io.*;
import java.util.*;

class ConcreteElement extends Element implements Serializable {
    void addSomethingTo(Element oei) {
	oei.add("TEST");
    }

    public static void main(String[] args) {
        try {
            ConcreteElement e1 = new ConcreteElement();
            ConcreteElement e2 = new ConcreteElement();
            
            ByteArrayOutputStream out = new ByteArrayOutputStream();
            ObjectOutputStream po = new ObjectOutputStream(out);
            po.writeObject(e1);
            
            byte[] b = out.toByteArray();
            
            ByteArrayInputStream in = new ByteArrayInputStream(b);
            ObjectInputStream pi = new ObjectInputStream(in);
            Object o = pi.readObject();
            ConcreteElement l = (ConcreteElement)o;
            
            e2.addSomethingTo(l);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

Now I've compiled the stuff with javac (1.4.2) and it runs without any
errors.  Then I jarred the two classes into an jar file and used
 gcj --main=test10.ConcreteElement -o test10 test10.jar
to compile an executable, but that gives me the following error:
act1
java.lang.NullPointerException
   at _ZN4java4lang11VMThrowable16fillInStackTraceEPNS0_9ThrowableE
(/site.opt/gcc-3.4/lib/libgcj.so.4.0.0)
   at _ZN4java4lang9Throwable16fillInStackTraceEv
(/site.opt/gcc-3.4/lib/libgcj.so.4.0.0)
   at _ZN4java4lang9ThrowableC1EPNS0_6StringE
(/site.opt/gcc-3.4/lib/libgcj.so.4.0.0)
   at _ZN4java4lang9ThrowableC1Ev (/site.opt/gcc-3.4/lib/libgcj.so.4.0.0)
   at _ZN4java4lang9ExceptionC1Ev (/site.opt/gcc-3.4/lib/libgcj.so.4.0.0)
   at _ZN4java4lang16RuntimeExceptionC1Ev (/site.opt/gcc-3.4/lib/libgcj.so.4.0.0)
   at _ZN4java4lang20NullPointerExceptionC1Ev
(/site.opt/gcc-3.4/lib/libgcj.so.4.0.0)
   at _Jv_AllocObject (/site.opt/gcc-3.4/lib/libgcj.so.4.0.0)
   at _Z10_Jv_selectiP6fd_setS0_S0_P7timeval (/site.opt/gcc-3.4/lib/libgcj.so.4.0.0)
   at _ZN3gnu3gcj7runtime11FirstThread9call_mainEv
(/site.opt/gcc-3.4/lib/libgcj.so.4.0.0)
   at _ZN3gnu3gcj7runtime11FirstThread3runEv (/site.opt/gcc-3.4/lib/libgcj.so.4.0.0)
   at _Z13_Jv_ThreadRunPN4java4lang6ThreadE (/site.opt/gcc-3.4/lib/libgcj.so.4.0.0)
   at _Z11_Jv_RunMainPN4java4lang5ClassEPKciPS4_b
(/site.opt/gcc-3.4/lib/libgcj.so.4.0.0)
   at JvRunMain (/site.opt/gcc-3.4/lib/libgcj.so.4.0.0)
   at __libc_start_main (/lib/libc.so.6)
   at _start (Unknown Source)


If the class test10.Element is not declared as abstract, the native
compiled executable again works without any errors.

I was using using: $> gcj --version
gcj (GCC) 3.4 20031210 (experimental)
on a linux box (don't know, if you need this info) for the above error message,
but it is still the same with 'gcj (GCC) 3.4.0 20040206 (prerelease)' and '3.5.0
cvs' from 10 Feb 2004.

Christian