Serialisation bug with abstract classes

[Christian Stuellenberg <gcj at stuellenberg dot de>]

Hello all,

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'm using: $> gcj --version
gcj (GCC) 3.4 20031210 (experimental)
on a linux box (don't know, if you need this info).

Hopefully this bug can be verified,
Christian