Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Appending objects to a file using serialization

1 view
Skip to first unread message

szim...@crcg.edu

unread,
Apr 29, 1999, 3:00:00 AM4/29/99
to
Hi,

I just got a strange problem here. I want to write objects of the same class
to one specific file. If I write some objects at one time there is no problem
but if I try to add objects after I have closed the file I am not able to
read the objects back. I tested it with several different data types such as
integer and String and it produdes always the same exception. Here are two
example applications that produce the error. Just call writeTest and
afterwards readTest and the same error as listed below should appear. Does
anybody know a solution for this problem??

Here are the examples:

import java.io.*;

public class writeTest
{
public static void main(String args[])
{
// Serialize the original class object
try
{
FileOutputStream fo = new FileOutputStream("test.tmp", true);
ObjectOutputStream so = new ObjectOutputStream(fo);
so.writeInt(10);

so.flush();
so.close();
}
catch (Exception e)
{
e.printStackTrace();
System.exit(1);
}

// Serialize the original class object
try
{
FileOutputStream fo = new FileOutputStream("test.tmp", true);
ObjectOutputStream so = new ObjectOutputStream(fo);

so.writeObject("Steffen");
so.flush();
so.close();
}
catch (Exception e)
{
e.printStackTrace();
System.exit(1);
}
System.exit(0);
}


import java.io.*;


public class readTest
{
public static void main(String args[])
{
// Deserialize in to new class object
try
{
FileInputStream fi = new FileInputStream("test.tmp");
ObjectInputStream si = new ObjectInputStream(fi);
int i1 = si.readInt();
String s1 = (String)si.readObject();

System.out.println("Integer1: " + i1);
System.out.println("String2: " + s1);

si.close();
}
catch (Exception e)
{
e.printStackTrace();
System.exit(1);
}

System.exit(0);
}
}

Here is the error message:
java.io.StreamCorruptedException: Type code out of range, is -84
at java.io.ObjectInputStream.peekCode(ObjectInputStream.java:1280)
at java.io.ObjectInputStream.refill(ObjectInputStream.java:1401)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:273)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:232)
at readTest.main(readTest.java:16)
Process Exit...

Is this a general problem and does anybody know a work around?

Thanks,
Steffen

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own

Thomas Muller

unread,
Apr 29, 1999, 3:00:00 AM4/29/99
to

szim...@crcg.edu wrote in message <7g9tpk$jed$1...@nnrp1.dejanews.com>...

>Hi,
>
>I just got a strange problem here. I want to write objects of the same
class
>to one specific file. If I write some objects at one time there is no
problem
>but if I try to add objects after I have closed the file I am not able to
>read the objects back. I tested it with several different data types such
as
>integer and String and it produdes always the same exception. Here are two
>example applications that produce the error. Just call writeTest and
>afterwards readTest and the same error as listed below should appear. Does
>anybody know a solution for this problem??


Yepp. This is a familiar problem. If you append the objects to the file,
opening the file in append-mode for each file to serialize, the objects will
be separated with 4 "blank" bytes. The -84 error you get is your
ObjectInputStream trying to deserialize an object starting on a blank.

There are 2 solutions to this problem, non particulary preferrable.

1. In you deserialization-algorithm, make sure to skip 4 bytes between each
readObject().

2. In your serialization-algorithm open the file with a RandomAccessFile and
utilize seek to set the head on file.length(), and serialize the object via
an outputstream-implementation wrapping the RandomAccessFile applied (one of
the annoying sufferings of Sun not defining OutputStream and InputStream as
interfaces instead of classes).

Personally I use the second solution, since this provides the liberty to
serialize several objects each time the file is opened, without cluttering
the code with skipping 4 bytes between each serialization. For serialization
I've written a RandomAccessFileOutputStream which inherits OutputStream, but
provides access to the methods of the underlying RandomAccessFile as well.
On top of this i wrote a SerializeToFileService-kind of package with an
interface defining methods for write/read/delete. The read-method returns an
Iterator of the serialized objects. Two classes provide an implementation,
one serializing to several files, one serializing to a single file. A
factory let's clients get the proper implementaion given some magic
arguments.

-Thomas


0 new messages