As Kirill mentioned, this is related to the way Java serialization is
written.
The internal data structure of JAXB 1.0.x (BGM) heavily uses binary
trees. When serialized, Java serialization engine traverses this in a
DFS fashion, causing a very large stack, often hit StackOverflowError.
As some people mentioned, -Xss could be used to increase the stack size.
What many people doesn't know, however, is that this setting takes no
effect on the first thread that executes main (because this thread is
created by the OS with the default stack size.) For you to benefit from
-Xss, you have to start another thread and use that thread to do JAXB
operations. If you look at XJC's Driver class, you'll see that we launch
a new thread just because of this.
bgm.ser is used for on-demand validation and unmarshalling validation.
If you don't need those, you can instruct XJC not to generate those
artifacts. I don't remember if this actually surpress the generation of
bgm.ser right now, but this should be enough hint for XJC not to do so.
So try:
<xs:annotation>
<xs:appinfo>
<jaxb:globalBindings>
<xjc:noValidator />
<xjc:noValidatingUnmarshaller />
</jaxb:globalBindings>
</xs:appinfo>
</xs:annotation>
See more about this on
http://java.sun.com/webservices/docs/1.6/jaxb/vendorCustomizations.html#lwruntime
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com