Build and validate SIRI 2.1 on JDK 24+ despite the JDK built-in XML catalog

[vpaturet]

Problem

The project does not build on JDK 24 or newer, and SiriValidator cannot validate SIRI 2.1 documents on those JDKs either.

JDK 22 introduced a built-in XML catalog in java.xml (JDK-8306055), and JDK 24 added the W3C DTDs and XSDs to it (JDK-8344800). One of its rules is a suffix match that rewrites every schema location ending in XMLSchema.xsd to the JDK's own copy of the XML Schema schema-for-schemas:

<systemSuffix systemIdSuffix="XMLSchema.xsd" uri="schema10/XMLSchema.xsd"/>

The SIRI 2.1 standard ships the W3C xml-namespace schema as xml/2009/01/XMLSchema.xsd, imported from siri_utility/siri_types.xsd. On JDK 24+ that file is shadowed, xml:lang is no longer declared, and loading the schema fails:

src-import.3.1: The namespace attribute, 'http://www.w3.org/XML/1998/namespace', of an <import> element
information item must be identical to the targetNamespace attribute, 'http://www.w3.org/2001/XMLSchema' ...
src-resolve: Cannot resolve the name 'xml:lang' to a(n) 'attribute declaration' component.

The XSDs are part of the standard and are left untouched. Upstream SIRI-CEN uses the same file name.

Changes

Build

• pom.xml: pass a user catalog (src/main/xjc/siri-2.1-catalog.xml) to XJC through the cxf-xjc-plugin catalog option for the SIRI 2.1 xsdOption. A user catalog takes precedence over the JDK built-in one, so the import resolves to the bundled file.
• Bump maven-compiler-plugin 3.8.0 → 3.16.0, using <release>11</release> instead of source/target. The bytecode target is unchanged.
• Bump cxf-xjc-plugin 4.0.0 → 4.2.0.

Runtime

• New RelativeSchemaResourceResolver, set on the SchemaFactory in SiriValidator. It resolves schema imports relative to their base URI (file or jar URLs) without consulting catalogs. Without it, SIRI 2.1 validation throws on JDK 24+ for consumers of the published jar. This affects the released 2.0.6 as well.
• The resolver returns an LSInput that carries only the resolved system id; it opens no stream itself. Xerces opens the document, and only if it has not already traversed it, so nothing is leaked for the many schemas that are included or imported more than once.
• Xerces skips its accessExternalSchema check for any location a resource resolver has resolved: the resolver is the access policy. The resolver therefore only resolves file: and jar: locations, which keeps it inside the bundled schema tree, and returns null for anything else so that Xerces applies its own access check and catalog. The bundled XSDs contain no absolute schema locations outside documentation text, so this path is never taken today.
• The resolver keeps the deprecated URL(URL, String) constructor on purpose: jar: URIs are opaque, so URI.resolve() returns the relative reference unchanged instead of resolving it. A comment in the code records this.
• SiriValidator previously rebuilt the whole SIRI schema set (86 XSD files) on every validate() call. Schema is immutable and thread-safe, so one compiled Schema per version is now built lazily through ConcurrentHashMap.computeIfAbsent and reused, as already done for the JAXB contexts. Cache hits take no lock, and a failed build is not cached so a later call retries.

Verification

Run	Result
mvn clean install on JDK 25	success, 14 tests pass
mvn clean install on JDK 11	success, 14 tests pass
Validating SIRI 2.0 and 2.1 fixtures on JDK 25 with the schemas loaded from inside the OTP shaded jar (otp-shaded-2.11.0-SNAPSHOT.jar, which bundles siri-java-model 2.0.6), with this PR's two validator classes placed ahead of the jar	2.1 fixtures valid; 2.0 fixture reports the same content errors as 2.0.6

Before the resolver change, SiriXmlTest failed on JDK 25 with the catalog error above, which is how the runtime problem was found. The bundled 2.0.6 fails the same way in the OTP jar run.

Performance (schemas from the OTP jar, 200 timed calls after 50 warm-up calls, median per validate() call)

Document	2.0.6 on JDK 11	2.0.6 on JDK 25	PR on JDK 11	PR on JDK 25
et-2_1.xml (19 KB)	38.1 ms	fails	1.6 ms	1.4 ms
vm-2_1.xml (3 KB)	39.6 ms	fails	1.4 ms	1.2 ms
et.xml (19 KB, SIRI 2.0)	35.2 ms	41.3 ms	1.6 ms	1.5 ms

The first call still takes about 1.5 s to compile the schema set, now once per version per JVM instead of on every call. Open file descriptors stayed flat over the 250 validations in every configuration.

Notes

• CI still builds on Java 11 and is unaffected. The plugin bumps are compatible with JDK 11.
• jdk.xml.jdkcatalog.resolve cannot be used as a workaround: it only governs what happens when the built-in catalog fails to resolve, and does not disable it. See the java.xml module summary, section "JDK built-in Catalog".