This "apparent" regression is due to a patch available in the latest JAXP RI and in JDK 7 which isn't in 6u2. This is the original bug report,
In summary, the original optimization introduced in JDK 6 to avoid linear-space algorithm was a bit aggressive, and resulted in false positives in a few cases. Thus, this optimization had to be adjust to handle a more restricted set of cases. Hence, the difference in behavior between 6u3 and the latest JDK 7 build (which is in synch with the latest JAXP RI). In fact, it the test in this report should behave just like in JDK 5. If the maxOccurs is used on the xs:element rather than xs:sequence, then the optimization should kick in, thus showing the difference between JDK 5 and JDK 7.
The fix is now available on java.net through the lastest build in the download section. Fatal errors now reported for the above JCK tests in situations that led to OOM previously. Please refer to the JAXP compatibility guide, section "Feature for Secure Processing", and note that the feature is turned on by default when using the SAX or DOM factory, but not for the SchemaFactory.
This fix will be considered in future JDK 6 update releases.
While XML Schema tests for JAXP report expected error message, corresponding JAXB tests with the same schemata fail with OOME or hang. Since this CR was initially created against JAXB tests, it cannot be considered fixed.
JAXP tests fail with message like"Fatal Error: Current configuration of the parser doesn't allow a maxOccurs attribute value to be set greater than the value 5,000.":
These tests are run using SAXParserFactory.
JAXB tests fail with either OOME:
JAXB tests hang:
It seems like the reason of these failures is that FEATURE_SECURE_PROCESSING is false by default in javax.xml.validation.ValidatorHandler. This handler is used in JAXB .
I think the fix for these failures (OutOfMemoryError is thrown) is to either:
1. Make FSP == true by default. This will require a CCC request.
2. To work further on fixing of this bug in JAXP in some other way.