StreamCorruptedException problem

Question

I am trying to append serialized objects to a file without doing it all at once, ie, writing some objects to the file (for example three objects), ending the application, closing the object input stream and file storing the serialized objects. Late I would restarting the application and add more objects (say two objects), so the file grows over time.
I have a simple objectWriter class. In the add object program I create an instance of objectWriter, write some instances of the serialized class to the input stream, then close it. It looks like this:
ow = new ObjectWriter();
//write one or more serialized 'Contact' objects
ContactObject co = new ContactObject( string1, string2 );
ow.writeObject(co);
//Finish up
ow.closeOOStream();
The ObjectWrite constructor and methods look like this:
public ObjectWriter()
try
FileOutputStream fos = new FileOutputStream("ContactFile.ser", true);
oos = new ObjectOutputStream(fos);
catch (Exception e) {....}
public void writeObject(ContactObject _co)
try
oos.writeObject(_co);
catch (Exception e) {..}
public void closeOOStream()
try
oos.close();
catch (Exception e) {}
The append application seems to work without exception and when I examine the ContactFile.ser file, there does appear to be five objects in there.
But when I employ an ObjectReader class I get the error StreamCorruptedException after the third object is read. I wonder if it is therefore possible
to serialize objects in this way or must one use conventional text-based flat files to achieve such an end.
Thanks for any help.

Answer 1

qabpafi wrote:
Thanks for the interest Paul. Your comments are certainly worth taking into account.If you're interested in this approach, I can post a few details about this.
In order to encapsulate multiple streams into a single stream, you need to write the length of each stream so that the InputStream wrapper can read this to determine when to stop returning bytes, or how many bytes to skip in order to reach the next encapsulated stream. Since streams are generally not seekable (mark/reset is optional and limited in size), a block protocol should be used.
In particular, one way of doing this is to buffer the output as it is being written, and when the buffer is full, write the length of the buffer followed by the contents of the buffer. A block length of 0 can be a sentinel value indicating the end of a stream (and the start of the next stream). This way, an InputStream can pick these up and know when to stop returning bytes to the caller. Or, if not all the bytes are read, a request to move to the next stream can continue reading blocks until the 0-length block is encountered, indicating it's at the next stream.