Cleanup package structure and add support for Java Platform Module System

Start with the NamespacePrefixMapper signatures in both SiriXml utility classes and review the dependency and package findings in the issue. Check .github/workflows/push.yml, jaxb-bindings.xml, and the compiler settings to understand the JDK 11 build. Done means the API/module-path decision is documented and the chosen JPMS approach is validated against the listed package and dependency constraints.

I took a quick look at what is needed to support JPMS (adding module-info.java) to this library. Below is the claude report.

Supporting JPMS has many benefits - not limited to these:

• Better performance (restrict reflection - code can be optimized)
• Future JDKs will be stricter
• Slim API surface help reducing context - helping humans as well as AI
• Multiple versions of the same lib can be used in one VM, supporting backwards compatibility
• Fine grained dependency graphs helps tooling (build in seconds, not minutes for OTP)

Cons:

• Maintaining the module-info.java

Investigation: adding module-info.java (JPMS) to siri-java-model

Environment note first:
CI builds with JDK 11.

Package inventory (what module-info.java would need to export)

Handwritten:

• org.entur.siri, org.entur.siri.adapter, org.entur.siri.validator
• org.entur.siri21.util, org.rutebanken.siri20.util

Generated (confirmed for 2.0, inferred for 2.1 from jaxb-bindings.xml — same pattern):

• uk.org.siri.siri20 / uk.org.siri.siri21
• uk.org.ifopt.siri20 / uk.org.ifopt.siri21
• uk.org.acbs.siri20 / uk.org.acbs.siri21
• eu.datex2.siri20.schema._2_0rc1._2_0 / eu.datex2.siri21.schema._2_0rc1._2_0
• net.opengis.gml.siri — 2.1-only, generated from a GML schema binding not mentioned in CLAUDE.md
• org.w3._2001.xmlschema — shared Adapter1/Adapter2 classes for the dateTime/duration bindings; both 2.0 and 2.1 xjc runs generate into this same package/class names (harmless today since it's one jar/one module, just worth knowing)

The blocker: a hard split-package conflict

SiriXml.toXml(Siri, NamespacePrefixMapper, ...) in both util classes is public API typed against com.sun.xml.bind.marshaller.NamespacePrefixMapper, supplied by the compile-scope dependency com.googlecode.jaxb-namespaceprefixmapper-interfaces:JAXBNamespacePrefixMapper. That jar's classes live in:

• com.sun.xml.bind.marshaller — the exact same package used by the real JAXB RI (com.sun.xml.bind:jaxb-core/jaxb-impl, currently test-scope here)
• com.sun.xml.internal.bind.marshaller
• org.eclipse.persistence.oxm / .internal.oxm

It's a compile-time stub deliberately shaped to shadow whichever real JAXB runtime (Metro or EclipseLink MOXy) a consumer puts on the classpath — that trick only works on the classpath. On the module path, having this shim module and a real jaxb-impl/MOXy module present together is a guaranteed java.lang.module.FindException (two modules can never contain the same package, exported or not). Since this library's whole purpose is marshalling XML — which requires a real JAXB runtime at deploy time — any consumer trying to run this fully modularized alongside an actual JAXB implementation will hit this immediately.

This is the one finding that needs a decision before module-info.java is worth writing:

• keep the library usable (as today) mainly via the classpath/unnamed module, and add module-info.java purely for consumers who read this jar on the module path without also modularizing their JAXB runtime — narrow but non-breaking, or
• break the NamespacePrefixMapper API (replace it with a type this library owns, or drop the overload) so the module no longer needs that shim as a compile dependency — clean, but an API-breaking change.

Other things module-info.java needs to account for

• Reflection for JAXB (un)marshalling: generated classes use private fields; the JAXB runtime a consumer supplies (unknown module name, chosen by them) needs reflective field access. The practical answer is open module ... (or opens-per-package) rather than plain exports, since we can't predict/opens ... to an implementation module we don't control.
• Dependencies without a real module identity: jackson-databind, jackson-core, jackson-module-jakarta-xmlbind-annotations, slf4j-api (2.0.7), and JAXBNamespacePrefixMapper all lack module-info.class and Automatic-Module-Name — they'd resolve as automatic modules with filename-derived names (brittle, not guaranteed stable across versions). Only jakarta.xml.bind-api and jackson-annotations ship real module descriptors.
• Module naming: no existing Automatic-Module-Name is set today, so any current module-path consumer relies on the jar-filename-derived name (siri.java.model). Publishing a module-info.java with an explicit name (suggest org.entur.siri) changes that name — a breaking change for any such consumer, worth a release note.
• Compiler plugin: maven-compiler-plugin 3.8.0 with <source>/<target>11</target> supports module-info.java fine, but since it's built with --release 11 semantics missing, consider switching to <release>11</release> so building on newer JDKs doesn't accidentally leak newer JDK APIs — a good companion change, not required for JPMS itself.

Suggested next step

Given the split-package issue, decide the NamespacePrefixMapper question first since it determines whether this is a same-version additive change or needs a major version bump:

• draft module-info.java as an open module, keeping the current NamespacePrefixMapper API as-is, documenting the module-path caveat, or
• first look at removing/replacing the JAXBNamespacePrefixMapper dependency.