If you are using the latest JDK 1.7 update 45 and you parse a lot of XML using JaxB, then you may suddenly start encountering this error:
Exception in thread “main” javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,1]
Message: JAXP00010001: The parser has encountered more than “64000” entity expansions in this document; this is the limit imposed by the JDK.
So what changed from the previous release (update 40)?
After some digging through the OpenJDK source tree, it looks like there has been some notable churn in the Xerces packages, particularly WRT to (XML)SecurityManager. Note: Not to be confused with java.lang.SecurityManager.
At first the latter seems to be the culprit as it touches the lines the exception is thrown from, but closer inspection reveals that commit 32a6df99656c is just a load of refactoring and renaming. Commit 8426c41b7922 appears to be responsible.
What has actually changed here is a (XML)SecurityManger is actually being configured by default, where previously the default seems to have been for none.
I can only guess if this was an intentional change, but it seem sensible to have a security manager by default and perhaps this was the supposed to have been configured by default all along. It seems no many people have hit this problem yet. Given this was (albeit unintentionally) previously disabled, it seems ok to disabled the entity expansion limit again as a short-term work around. At least, better to disable the entity expansion limit than try and pin at an older version of the JDK.
Update 2013/11/6: Looks like this “fix” was back-ported to OpenJDK 1.6 at least on RHEL as of “java-1.6.0-openjdk.x86_64 1:188.8.131.52-184.108.40.206.14.el6_4”. See the RHEL change log. This change is also mentioned in this RHEL security advisory. I would check the source, but hg.openjdk.java.net is down at the moment.
Update 2013/11/13: Seems there is an actual bug open for this now, though currently fix-version is set to ‘8’.