Summary: Serializing recursively calls writeObject, resulting in
         java.lang.StackOverFlowError being thrown when the
         object graph is deeply nested (example: long link list).
         Since serialiation is being performed on a server
         that spawns a thread for each client, it is not possible
to up the stack size to workaround this capacity limitation for
each thread.

Customer mail message:

Apparently an object O is serialized in a "pre-order" walk of the
object graph rooted at O. Thus if O points to O', O' is
serialized first, and then O. JDK 1.1.6 and earlier versions seem
to implement this by using the stack to do the recursion.

This has the hugely unfortunate property of limiting the size of
the graphs that can be serialized. Trying to serialize a linked
list of 1000 elements blew my stack on an WinNT! In essence, one
cannot serialize an object graph which can grow arbitrarily
large.

I am led to believe that it is not possible in Java to grow the
stack size arbitrarily in a data-dependent manner from inside the
JVM. Why not do this recursion in the heap then?

Or, perhaps even better, why not do the serialization in a
"post-order" walk (generating a handle on O', stashing that away
in a table, finishing the serialization of O (using the handle
for all future accesses to O') and then coming back to serialize
all the objects in the table that have not yet been serialized)?

Are any patches available for this functionality? I can try to
fake it in my application, but the problem is that I do not
control the code being loaded into the JVM --- so I cannot
control the {write/read}Object methods for all classes.