EVALUATION
The attached serialization stream (file "store.txt") contains a deeply nested graph of serialized objects-- its maximum depth is 687, with the deep containment mostly caused by instances of com.sun.org.apache.xerces.internal.dom.ElementNSImpl-- which is generally problematic for Java object serialization. See 4152790, as well as page 220 of Josh Bloch's book "Effective Java", which cautions against deep containment in serialized form design.
Regarding why a StackOverflowError occurs using this particular stream with 5.0u8 (on Windows XP) but not 5.0u7, I can't say for certain. I can't reproduce the attached test case's failure with 5.0u8 on Solaris/SPARC (with either -client or -server) with the default stack size. There was no significant change in ObjectInputStream's use of stack space in between 5.0u7 and 5.0u8 (e.g., no new method invocations), although there were a couple of local variables added to one of the methods involved. But the precise amount of stack space actually consumed by an operation surely varies slightly due to many factors stemming from the underlying platform, the VM version, the core libraries version, etc.
Because of these inherent vagaries, it's difficult to characterize the reported change in behavior as a regression. The attached test case is clearly very "close to the edge" in stack space consumption with the client VM's default stack size. If I lower the stack size to 500KB with -client (from the default 512KB on Solaris/SPARC), I do reproduce the failure on Solaris/SPARC with 5.0u8, but not 5.0u7. I can reproduce the failure on 5.0u7 too with the stack size set down to 480KB, demonstrating a slight difference in sensitivity between the releases. Increasing the VM's per-thread stack size should work around this failure: see the -Xss VM option.
|
Java