The length of entity "[xml]" is "100,001" that exceeds the "100,000" limit

[ewillink]

The eclipse-simrel/.github#75 change to Java 25 seems to have happened mandating Java 25 for normal builds on Jenkins.

However using Java 25 for 2026-09 and JustJ gives (https://ci.eclipse.org/uml2/job/uml2-promoter/99/console)

[INFO] Adding repository https://download.eclipse.org/releases/latest
[Fatal Error] :239129:6704: JAXP00010003: The length of entity "[xml]" is "100,001" that exceeds the "100,000" limit set by "jdk.xml.maxGeneralEntitySizeLimit".
[ERROR] [704af208-eda8-42c4-b0e4-d6f9dfdddfdc][plugin>org.eclipse.tycho:tycho-eclipse-plugin:4.0.5] Provisioning exception
org.eclipse.equinox.p2.core.ProvisionException: Unable to read repository at file:/home/jenkins/.m2/repository/.cache/tycho/https/download.eclipse.org/releases/2026-09/202609091000/content.xml.xz.
    at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryIO.read (MetadataRepositoryIO.java:84)
    at org.eclipse.equinox.internal.p2.metadata.repository.XZedSimpleMetadataRepositoryFactory.load (XZedSimpleMetadataRepositoryFactory.java:86)
...
    at org.eclipse.tycho.p2.target.facade.TargetPlatformFactory.createTargetPlatform (TargetPlatformFactory.java:27)
    at org.eclipse.tycho.eclipserun.EclipseRunMojo.createEclipseInstallation (EclipseRunMojo.java:364)
    at org.eclipse.tycho.eclipserun.EclipseRunMojo.execute (EclipseRunMojo.java:328)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:126)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:328)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:316)

Although JustJ does not appear on the stack, this seems to be a good place to ask about a problem affecting standard JustJ usage.

Is it a platform bug that the 100,000 limit is imposed?
Do maven configs need changing as per google/google-java-format#1210?
Must every maven use of XML add a larger jdk.xml.maxGeneralEntitySizeLimit just in case?

[merks]

From which update site are you providing the p2 bundles? This issue was addressed in p2 almost 2 years ago. And just these past days I’ve update a bunch of builds that use p2.manager.

[merks]

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

[merks]

This is kind of a similar question

eclipse-platform/eclipse.platform#2918

[ewillink]

Nothing to do with update sites. I've managed to reproduce on a QVTd JUnit test that was fine using Eclipse 2026-03 and Java 21, but fails with the sole change to Java 25.

Thread [main] (Suspended (exception SAXParseException))	
	SAXXMIHandler(XMLHandler).fatalError(SAXParseException) line: 712	
	ErrorHandlerWrapper.fatalError(String, String, XMLParseException) line: 181	
	XMLErrorReporter.reportError(XMLLocator, String, String, Object[], short, Exception) line: 400	
	XMLErrorReporter.reportError(XMLLocator, String, String, Object[], short) line: 327	
	XMLErrorReporter.reportError(String, String, Object[], short) line: 284	
	XMLEntityScanner.checkLimit(XMLSecurityManager$Limit, Entity$ScannedEntity, int, int) line: 1009	
	XMLEntityScanner.checkEntityLimit(XMLScanner$NameType, Entity$ScannedEntity, int, int) line: 968	
	XMLEntityScanner.scanLiteral(int, XMLString, boolean) line: 1169	
	XMLDocumentScannerImpl(XMLScanner).scanAttributeValue(XMLString, XMLString, String, XMLAttributes, int, boolean, String, boolean) line: 980	
	XMLDocumentScannerImpl(XMLDocumentFragmentScannerImpl).scanAttribute(XMLAttributes) line: 1532	
	XMLDocumentScannerImpl(XMLDocumentFragmentScannerImpl).scanStartElement() line: 1372	
	XMLDocumentScannerImpl$ContentDriver(XMLDocumentFragmentScannerImpl$FragmentContentDriver).next() line: 2736	
	XMLDocumentScannerImpl.next() line: 635	
	XMLDocumentScannerImpl(XMLDocumentFragmentScannerImpl).scanDocument(boolean) line: 551	
	XIncludeAwareParserConfiguration(XML11Configuration).parse(boolean) line: 890	
	XIncludeAwareParserConfiguration(XML11Configuration).parse(XMLInputSource) line: 826	
	SAXParserImpl$JAXPSAXParser(XMLParser).parse(XMLInputSource) line: 137	
	SAXParserImpl$JAXPSAXParser(AbstractSAXParser).parse(InputSource) line: 1225	
	SAXParserImpl$JAXPSAXParser.parse(InputSource) line: 629	
	SAXParserImpl.parse(InputSource, DefaultHandler) line: 328	
	XMILoadImpl(XMLLoadImpl).load(XMLResource, InputStream, Map<?,?>) line: 175	
	ASResourceImpl(XMLResourceImpl).doLoad(InputStream, Map<?,?>) line: 260	
	ASResourceImpl(ResourceImpl).load(InputStream, Map<?,?>) line: 1563	
	ASResourceImpl(ResourceImpl).load(Map<?,?>) line: 1342	
	ResourceSetImpl.demandLoad(Resource) line: 259	
	ResourceSetImpl.demandLoadHelper(Resource) line: 274	
	ResourceSetImpl.getResource(URI, boolean) line: 406	
	AbstractTestQVT.loadQVTiAS(OCL, URI) line: 240	
	QVTrSerializeTests.doSerialize(URI, URI, URI, Map<String,Object>, boolean, boolean, String[]) line: 128	
	QVTrSerializeTests.doSerializeRoundTripFromCS_usingOCL1(URI, String[]) line: 89	
	QVTrSerializeTests.testQVTrSerialize_SimplerRelToCore() line: 206	
	...
	RemoteTestRunner.run() line: 443	
	RemoteTestRunner.main(String[]) line: 211	

It would appear that Java 25 introduces a 'helpful' XML size limit in XMLEntityScanner.checkEntityLimit which may suit file name typos for small XML users but kills bug-free big XML users, unless they set an explicit limit.

It would seem that for compatibility XMLLoadImpl.load should set a big XML limit.

[merks]

Well you did come here with an update site stack, so you should expect an answer related to that.

Yes. If you read the other discussion, it’s a general XML issue.

You can set the features of the parser via options in your resource factory for your own use cases.

[ewillink]

For my JUnit test I need to revert 3 of the changes in https://bugs.openjdk.org/browse/JDK-8343006 with

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

From a legacy usage point of view, Java 25 corrupts java.xml module. I expect Eclipse to hide OS/UI/... eccentricities so that my working code is portable. IMHO it is therefore just a matter of whether the platform or EMF should 'revert' the Java 25 corruption. But perhaps the problem is that the simple problem of reading an XML file has got hijacked by security concerns over nested imports.

It seems very very wrong that standard JustJ usage is broken by Java 25. If the platform / EMF fixed the problem, users would be unaffected. As it is every JustJ user must discover/diagnose/fix the known issue.

[merks]

You didn’t answer my question about the source of the p2 bundles you are using for promotion and seem to ignore the fact p2 has addressed the issue. I can only repeat myself, but I won’t repeat myself a third time.

It work fine for EMF

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

You start with an update site issue, go on to assert the problem has nothing to do with update sites and now seem to believe that someone else needs to do something to solve your problems. But that’s not going to happen. You see that p2 addressed the issue by configuring the options it uses; I shared a link. That is what you need to do too. And JustJ functions well when used with a recent p2.

Hitting the jvm with general options that would apply everywhere is not planned. I also don’t plan that for EMF. So best focus on addressing the issue specifically for your use case.

I agree the JDK changes seem questionable and overtly paternal, but no one asked me.

[ewillink]

Adding the same three -D's to the JustJ mvn launch solves the original problem.

Surely the platform must have a 'solution' to allow it to read a large workspace file, so why is that solution not made available to users too?

[merks]

Enough surelies. Solve the problems however you see fit. Though you might want to ask yourself why it works for EMF without those options. The answer to my question would no doubt clarify that.

[ewillink]

(We agreed that it was nothing to do with update sites although the first observation pointed that way.)

The problem for the QVTd JUnit test arises from exploiting EMF's support for entities to save space (typically 20% net) and allow single location editing:

<!DOCTYPE pivot:Model [
<!ENTITY _0 "http://www.eclipse.org/ocl/2015/Library.oclas">
]>
...
   <ownedClasses xsi:type="pivot:Enumeration" xmi:id=",Swbo" name="AssociativityKind" superClasses="&_0;#+8+by"

The limits apply to the narrow entity (!ENTITY) rather than the overall 'entity' (file). It appears to be a bug that the 10000 limit is applied to the referenced URL contents which may be huge rather than to the entity value ("http://www.eclipse.org/ocl/2015/Library.oclas") which should be modest/small.

EMF (and the platform) works because EMF never uses entities in URLs.

I'm not sure why JustJ / Maven fails; I wouldn't expect them to read the files they are managing.

[merks]

They fail because the content has a huge number of entities, not really large entities. That’s in the p2 metadata serialization they read, evident from MetadataRepositoryIO.read. Lots of entities to represent line characters in the long attribute values for the licenses for example.