This bug is closely related to 4289039.

Suppose that a serializable class A is written either via default serialization
or by a custom writeObject() method which calls
ObjectOutputStream.defaultWriteObject() before writing custom data. If A
defines a custom readObject() method that invokes ObjectInputStream.available()
or any of the ObjectInputStream read methods (primitive, bytewise or object),
then the available/read operation will trigger a StreamCorruptedException. The
correct behavior would be for ObjectInputStream.available() to return 0, and
for the various read methods to throw an OptionalDataException (see 4388704).

Unfortunately, this correct behavior is difficult to implement due to the
serialization protocol flaw documented in 4289039: at the point in time when
A's custom readObject() is invoked, the next element in the stream could be
custom data, or it could be default field values. Calling available/read at
this point forces ObjectInputStream to interpret the next byte value in the
stream as the beginning of a block data header or other stream element (e.g.,
and object or string), when in fact it may be the first byte value of a
primitive field declared by A. The attached code demonstrates this failure
case.