How do I identify that I am at the last byte of a serialized Java object?

Question

What is (if there is any) terminating characters/byte sequences in serialized java objects?

I'm working on a small self-education project where I would like to serialize java objects and write them to a stream where there are read and then unserialized. Since, I will need to identify the borders between serialized objects and I can't be sure that the current object is not the last one, is there a terminating character that is always there that I can use as my identifier?

I noticed that there is a magic number ACED that allows me to identify the start of the object, so how do I identify the end?

EDIT: If there is no terminating character, is there any safe terminating characters/sequences that I can use (insert) to identify the end of the object?

Answer 1

In theory you should always be able to find the end of an object, in practice you cannot. I understand the problem is customised writeObject implementations that don't call either defaultReadObject or readFields have a non-standard representation.

I've played about with serialisation in the past. Including creating streams for use when I've been doing unusual things to the ObjectInputStream . It's not pleasant(!).

You can read the details in the spec , and the source is worth a read.

Answer 2

there are none. AFAIK the only requirement is that the deserialiser know when to stop reading, when given a corresponding serialisation. subject to that, the serialiser can write whatever it wants -- in any position not just the last.

if you're old skool dump a 32-bit length field at the beginning a refuse to handle objects bigger than 4 gig.

nu scool, you just make sure your read and your write logic are consistent and don't care about the length.

Answer 3

You can add a terminating object to your object stream. eg null or a special String.

However, I suggest that you instead convert the ObjectsStream to a byte[] and write the byte length of the byte[] followed by its data. This way each ObjectStream is independent and you always know where it finishes.

Answer 4

Have you considered applying a record-marking layer similar to HTTP Chunked encoding ?

The Chunked encoding is intended to solve a generalization of this scenario: identifying the end of a message of indeterminate length that both itself contains no identifiable end, and is embedded in a longer stream without ending it.