Bizarre ClassCastException when sending serialized objects

Question

I have two programs communicating with each other over a network using TCP and serialized objects. One of the programs uses an ObjectOutputStream to send the message, and the other uses an ObjectInputStream to receive it. The receiver has a thread that simply loops, receiving and processing messages one at a time.
Under normal circumstances, this works fine. However, sometimes the sender program has to send more than one message, one right after the other. I guess my assumption was that on the receiving end, they would somehow just "queue up" in the ObjectInputStream and the receiver would be able to read them one at a time. But instead, I get this bizarre ClassCastException whose message talks about members and objects from both messages that were sent. It is as though somehow the two objects received are being mangled together and interpreted somehow as one object. This is strange to me, since I am pretty sure TCP is supposed to guarantee in-order delivery of packets.
Can I not send multiple messages right after each other through an ObjectOutputStream and have them received in an ObjectInputStream? If not, what would be a good workaround?
If you need more details, it works like this. I have two classes that look like this:
class Class1 extends SerializableSuperclass
  Member1 m1;
class Class2 extends SerializableSuperclass
  Member2 m2;
}Sender sends an instance of Class1 and then immediately an instance of Class2. Receiver attempts to readObject() from the input stream and gets this exception:
Exception in thread "Thread-4" java.lang.ClassCastException: cannot assign instance of Class2 to field Class1.m1 of type Member1 in instance Class1
Isn't that bizarre? Two separate classes, and it is attempting to merge the two in some odd way.
How do I fix or work around this?
Thanks

Answer 1

These classes do not have those methods. They are simply message classes designed to hold data. Do you need to see the methods that call ObjectOutputStream's writeObject() and ObjectInputStream's readObject() methods?
The serializable superclass is there because it has other stuff including a field identifying the sender. It's basically a base message class.
Also, the member classes are serializable (serializability isn't the issue anyway; "class cast" is the issue).