[Eclipse 2026-09] New Java 25 XML limits cause problems with some plugins which process large XML files

[chrisrueger]

In bndtools we discovered that with new new Eclipse 2026-09 released today bndtools is not working properly because in our specific instance there is a repository configured which processes a large XML OSGI index which exceeds Java 25 internal xml limits.

e.g.

Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[263628,258]
Message: JAXP00010003: Die Länge von Entity "[xml]" ist "100.001" und überschreitet den Grenzwert "100.000", der von "jdk.xml.maxGeneralEntitySizeLimit" festgelegt wurde.
	at java.xml/com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(XMLStreamReaderImpl.java:652)
	at java.xml/com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.nextTag(XMLStreamReaderImpl.java:1353)
	at aQute.bnd.osgi.repository.XMLResourceParser.next(XMLResourceParser.java:193)

See for details and workaround bndtools/bnd#7412

Workaround:

set the following in eclipse.ini of the Eclipse instance you are running:

-Djdk.xml.maxGeneralEntitySizeLimit=0
-Djdk.xml.entityExpansionLimit=0
-Djdk.xml.totalEntitySizeLimit=0

or any other reasonably high value if you think 0 (unlimited) is too dangerous.

Question

Is there something Eclipse should do?
or plugin authors? (e.g. for bndtools we could set the limits directly on the XMLInputFactory but this would not work for older releases of our plugin.

In case this is the wrong repo for this issue, just let me know where I can move it to.

[merks]

For p2, it sets some of those here:

https://github.com/eclipse-equinox/p2/blob/919d7f33c451e19ca69a17b80281c3a7b253d4c8/bundles/org.eclipse.equinox.p2.repository/src/org/eclipse/equinox/internal/p2/persistence/XMLParser.java#L98-L109

I'm not sure entityExpansionLimit is needed?

I think the danger of these is overrated, but hey we're all entitled to an opinion. After all, this content is being used to load repositories from which the user is going to install bundles. So what, you're kill my process with some evil XML overload before I get a chance to install your evil content rather than encourage me to proceed and actually install said evil content and then run it in the JVM after it restarts at which point the evil I can do is way more than exploding your XML processor.

[ewillink]

When overloading XMLLoadImpl.makeParser to support entity references within URLs, entityExpansionLimit is definitely needed.

[merks]

This was more a question than a bug. After all, the Platform doesn't determine the size of the SimRel repository, nor the number of & or other entities that might be used in such a repository.

[chrisrueger]

Thanks @merks for your points.

For me, the primary issue here is not a security concern but a functionality/compatibility problem.

bndtools worked with these repositories before (up to Eclipse 2026-06), but with Eclipse 2026-09 now running on JDK 25, the new JAXP defaults can make bndtools unusable when it encounters a repository index exceeding those limits.

We can of course fix this in bndtools by configuring appropriate limits ourselves. However, that only fixes the problem for future bndtools versions. Users running an older bndtools version inside a current Eclipse release may still encounter the problem unless there is a workaround at the Eclipse/JDK level.

I also agree that this does not affect all bndtools users automatically. It only affects users who work with repository indexes large enough to hit the new limits.

I understand the security rationale behind the JDK change. My point is simply that, in this particular case, the practical impact we are seeing is a compatibility regression: an existing, legitimate repository can no longer be consumed by an otherwise unchanged bndtools installation after moving to the new Eclipse/JDK combination.

I don't want to blame anyone for this or expect Eclipse to solve the problem. My intention is mainly to discuss where the most appropriate place for a solution would be. A solution does not necessarily have to be a change in Eclipse either — even making users aware of the problem and documenting the available workaround could already be helpful for users of older bndtools versions or even other XML-processing Eclipse plugins.

[chrisrueger]

Just for further reference:

• https://docs.oracle.com/javase/tutorial//jaxp/limits/using.html
• https://bugs.openjdk.org/browse/JDK-8343006
• Failures due to new JAXP limits in JDK 24 eclipse-tycho/tycho#4526

[merks]

Yes, it's rather annoying. Yet another problem caused by the "it's for your safety and comfort" principles. One only finds and prevents such problems by testing new JDKs long in advance of strictly requiring such newer JDKs. Given the nature of XML and the rather long list of CVEs associated with things like how entities are processed, changing of the feature configuration of an XML processor is typically/generally/best left up to each individual processor itself.

As we see in the p2 example, we discovered the issue almost 2 years ago with Java 24 and took these steps in p2's XML processing utilities:

eclipse-equinox/p2@3b8d9d1

Yet in the following we see a related issue being prompted again because you can't simply fix the past:

eclipse-tycho/tycho#4526 (comment)

So even with the problem addressed, it still shows up again years later for older versions.

The only thing I can suggest is to configure your XML processor.

Maybe you're already doing stuff like this:

https://github.com/eclipse-equinox/p2/blob/919d7f33c451e19ca69a17b80281c3a7b253d4c8/bundles/org.eclipse.equinox.p2.core/src/org/eclipse/equinox/internal/p2/core/helpers/SecureXMLUtil.java#L42-L49

If not someone helpful is bound to raise the alarms a some point.

[chrisrueger]

Yes, it's rather annoying. Yet another problem caused by the "it's for your safety and comfort" principles.

I Agree. Thanks for your remarks. This helped to order my thoughts.

Maybe you're already doing stuff like this:
https://github.com/eclipse-equinox/p2/blob/919d7f33c451e19ca69a17b80281c3a7b253d4c8/bundles/org.eclipse.equinox.p2.core/src/org/eclipse/equinox/internal/p2/core/helpers/SecureXMLUtil.java#L42-L49

Yes we have.
https://github.com/bndtools/bnd/blob/master/aQute.libg/src/aQute/lib/xml/XML.java#L149

I think we just go forward fixing it there in bnd. Maybe we introduce a new bnd config property with a chain like this:

[chrisrueger]

Created bndtools/bnd#7416

[merks]

Yes, that sounds like the right approach!

[ewillink]

Today after being forced by the platform evolution to start using Java 25. I hit two new instances of this problem. (see eclipse-justj/justj.tools#14).

For a QVTd JUnit test there were too many entity references being resolved to save space in URL references. Fixable by a makeParser overload to revert the three corrupted limits.

Maven's invocation of JustJ is obviously unaware of what is being promoted and can hit limits. Fixable by three -D's on the Maven command line. JustJ should be using the improved P2 manager, but seemingly the improvements are inadequate or bypassed.

Yes, it's rather annoying.

No. It is a serious regression that is showing up in too many places. IMHO by default EMF's makeParser should revert the limits unless a new load option requests the new limited functionality.

[merks]

Everyone is entitled to an opinion. I’ve explained too many times that JustJ is not a problem, but you choose to overlook what I’ve explained. Keep installing an old version of p2 and keep complaining about its shortcomings. Your choice, but this will accomplish nothing.

This stands in sharp contrast to @chrisrueger carefully considering the nature of the problem. It’s not my choice to change the XML processing defaults. I have my options about those, but those opinions won’t change the decisions made by others. I also don’t feel it’s my business to override those decisions for all JVM clients or for all EMF extensions.

To me it seems best that each client makes their own decision for their own application. Opinions may differ, but that’s also my choice to make.

[ewillink]

I'm not knowingly installing an old version of P2. I use

		<eclipse.repo>https://download.eclipse.org/releases/latest</eclipse.repo>
		<justj.tools.repo>https://download.eclipse.org/justj/tools/updates/nightly/latest</justj.tools.repo>

but perhaps Tycho 4.0.5 confounds.

To me a limit of 10,000 on entities is just as stupid as say a Java compiler limiting comment @link's to 10,000 characters. I'm not suggesting affecting JVM clients, just EMF clients. Forcing people to the global 3 -D's solution has potential side effects. Fixing just EMF preserves EMF legacy without affecting JVM.

[merks]

No Yes you use, latest JustJ

https://github.com/eclipse-emf/org.eclipse.emf/blob/06abfe0471827d8619c42053e226535b53d12d3a/releng/org.eclipse.emf.parent/promotion/pom.xml#L32

But do you use the latest p2?

https://github.com/eclipse-emf/org.eclipse.emf/blob/06abfe0471827d8619c42053e226535b53d12d3a/releng/org.eclipse.emf.parent/promotion/pom.xml#L31

And yes, Tycho 4.x is using old p2 with what is now a historical shortcoming. Best to use Tycho 5.x. Your choice. No one can fix the past.

Anyway, the focus does not seem to be on moving forward but rather on questioning the questionable choices of the JDK. And even there, it seems a one track approach.

You can specify options via

https://github.com/eclipse-emf/org.eclipse.emf/blob/06abfe0471827d8619c42053e226535b53d12d3a/plugins/org.eclipse.emf.ecore.xmi/src/org/eclipse/emf/ecore/xmi/XMLResource.java#L116

You fixing your use case should be your focus. But that’s just my opinion. That being said, I will not hit EMF with a big hammer, so you actually don’t have so many viable options.

Note that EMF XML loading is a major digression from the topic of this thread and also of the topic of JusJ’s use of the p2 framework.

[ewillink]

And yes, Tycho 4.x is using old p2 with what is now a historical shortcoming. Best to use Tycho 5.x. Your choice. No one can fix the past.

Yes Tycho 5.0.4 fixes the XML Parser limits for JustJ (but not the classpath ordering regression that breaks dynamic JET templates forcing my OCL build to use 3.0.5. Sigh! time for yet another difficult debug and workaround. See eclipse-ocl/org.eclipse.ocl#2354)

[vogella]

See also #2931

[ewillink]

How is a useful/flexible application such as the Sample Reflective Ecore Model Editor's functionality to be preserved for big files? Must the user restart Eclipse after adding the three -D's to the Eclipse.ini or the Eclipse command line. Surely we cannot expect every XML processing application (e.g UML tools) to fix this corruption?

[merks]

Here's the latest incarnation:

#2931

I have no idea what the JDK folks are thinking. The limits seem so arbitrary. How is that 201 attributes on an element is a problem? But yes, they appear to expect every application to configure such things and that's pretty much what the applications have been doing as in the PR associated with the above issue.

[laeubi]

The limits seem so arbitrary. How is that 201 attributes on an element is a problem?

Using attributes to store large amounts of data is generally considered bad practice in XML - they have real limitations compared to elements when it comes to data modeling and parsing (as always, there's no normative answer here, so others may disagree).

That said, this discussion won't convince anyone to change their data model, nor does it help solve the actual problem. If someone wants to challenge the limit itself, the JDK bug tracker (as painful as that process is) - or Oracle support, if you have a paid contract - is the right venue. Here, we can only treat the JDK's behavior as a given constraint to work around.

[ewillink]

It's beyond arbitrary it's mindless. Yes big entities are a security violation opportunity, but no big entities doesn't stop a clever security violation being smaller. We might as well ban big DLLs since they have a larger security risk. #2931 demonstrates that I was wrong in suggesting that EMF is the place to fix the problem. There are significant non-EMF XML usages too. The platform should come with at least a reverting Eclipse.ini that would demonstrate how older platforms can be Java 25-proofed.

[merks]

Speaking of DLLs, yes that will be disabled by default too. There are already warnings printed about that that are avoided by

--enable-native-access=ALL-UNNAMED

[ewillink]

Using attributes to store large amounts of data is generally considered bad practice in XML

There are numerous reasons why large XML files may fall foul of the new limits; only a few may be dismissed as poor practice. For the OCL/QVTd case the problem was the use of entities to shorten URI references saving typically 20% on file size; arguably a good practice.