Summary: Serializing recursively calls writeObject, resulting in 
         java.lang.StackOverFlowError being thrown when the
          customer  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  customer  O is serialized in a "pre-order" walk of the
 customer  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  customer  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.

The recommended work-around is to define custom writeObject and readObject
methods which transmit the nested/linked data structures as a flat sequence of
objects.  One example of this is the writeObject/readObject methods of
java.util.LinkedList.  The following post to the rmi-users mailing list
explains another (similar) example:

http://swjscmail1.java.sun.com/cgi-bin/wa?A2=ind9909&L=rmi-users&F=&S=&P=34494

The cause of this problem is well-known. It looked like a
practical work-around existed of upping the native stack size.
However, this workaround is not sufficent when many threads
all all trying to serialize. 

More thought should be given to use heap space over stack space
to serialize a graph of objects. This is too risky a change
to make for JDK 1.2, but needs to be considered in the future.

  xxxxx@xxxxx   1998-06-26

Will fix for merlin. The new mechanism wouuld switch from a recursive algorithm 
to an iterative one at a predetermined recursion depth. See comments.

  xxxxx@xxxxx   2000-06-15

Not enough time/resources to fix this for merlin.  Will leave open for
consideration in a future release.

  xxxxx@xxxxx   2000-12-27

I saw this problem as well.  I had a file that I could read and write from
JDK 1.2 fine.  But when I switched to 1.3, I got a stack overflow error.

I've hit this problem too, only I've got one thread and a really big data structure and I'm using -ss200m and I still get a stack overflow.  Anything bigger than 200 gives a windows exception or an out of memory error.

I can't believe they are not fixing this for merlin... 
Sometimes Sun drives me nuts...

we use serialization to cache big database structure...
can't use it because of this error

Serialization is fundamental to nearly every significant
Java project, and while this bug remains outstanding, it 
simply can't
be trusted.  Any minor change to the way one serialized 
object refers
to another can suddenly, and unfixably break the 
application.  The
only work-arounds are custom serialization and changing the 
startup
arguments, neither of which can work in general, the second 
of which
is sensitive not just to the changes you make but very 
specific ways
in which you might use the program.

This bug is a horrible gaping wound in a vital organ of the 
Java
beast, and that this bug has lasted more than 3 years 
without a fix
tells me that the priorities of the Java development team 
are
seriously flawed.  In all applications, especially 
enterprise
applications, robustness is of paramount importance, and 
this bug
means that what worked before may, in only subtly different
circumstances, start failing miserably and horribly.

This bug MUST be fixed NOW.  As far as I'm concerned, 1.4 
should be
delayed to get this fix in, and if not, a service patch 
should be
released immediately afterwards/separately to address it.

<shakes head>

following minor changes: any introduction of a reference
between objects that previously weren't linked can
suddenly break the entire program.

I have a case where the deserialization throws 
StackOverFlowError on Jserv with JDK1.1.8, but not on 
JDK1.3.1 or running standalone (without Jserv) with either 
versions of JDK.  This is on Solaris.

i have encountered this bug while trying to serialize a
knowledge base, which contains the dependency graph for a
(possibly) large Java program.
upping the stack size doesn't help, and besides, i need that
space for 
the heap!

sun, please fix this bug NOW.  otherwise, serialization of
any interesting data structure is impossible.  now, i have
to implement
custom serialization of my edge lists and be very careful
not to re-create a fully connected object graph in the future.

come on, sun, this is second-year computer science stuff!

One more comments: Bug doesn't seem to happen as offen on
Linux, but
that's likely due to a larger default process-stack size
anyways. (Sun's 1.3.1
on redhat 7.x) Only seen bug with Solaris on Sparc. (x86
ignored :-)

We've seen this bug with jdk1.3.1_01 and 1.3.1_06 as well as
the mentioned
versions.  In our case, there are many objects (not 1000,
but a few hundred)
but its a fully connected object graph.  Have not tested
this with jdk1.4, but 
our production environment is jdk1.3 for the near future. 
Since this is 'in
progress' and no comments from sun for about 2 years, it
would be nice
to know the progress of this one, and if a 'fix' would be
made available to
jdk1.3 if its fixed in a future version of jdk 1.4.x 
However, I have to 
assume that this dropped off sun's radar list. (Bug since
1.1? Geesh...)

I met this bug in my product.
Jdk1.4.1_01 and Jdk1.4.1_02 on windows.
I can not believe why this bug has not been fixed yet.

Arrgh, still not fixed! Here's another example: DOM versions
that implement Node.getNextSibling() using a reference to
that sibling throw a StackOverflowError when serializing a
DOM that has elements with some 1000 children (which is
quite common). I cannot use such an implementation in an EJB
context.

See also
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4284,
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5144, and
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18925.

The problem is very common if you try to serialize a
(relative large) recursive structure w/o special handling.

Using heap stack is not difficult at all. I believe that it
would take not more than a single day (max two) to change
the code...

Until this bug is fixed serialization mechanism must only be used in simple collage homeworks.(Just simple ones) and avoid using in enterprise projects

7 years now: time to fix it, maybe? People use Java for things bigger than cell phones, you know.

I can build and run this big hairy problem, but I can't save the object graph for future analysis. In my business, this kind of thing is enough to turn clients away from Java. 

Oh boy....

I hit this problem aslo,8 years,please fix it,ok?

The same situation in 1.5.0_08 and 1.6.0b

Happy Anniversary! 9 years!!! I believe a tradional gift of pottery is in order.

10 Years and counting!
Any plans on fixing this? ever?

This is a *bug*, not an RFE, and needs to be fixed ASAP!

when this is gonna be fixed!! PLEASE~~~~  it is almost 10 years!!!!