Stream: hapi
Topic: XPP3 Conflict with java.xml module
Keith Boone (Oct 09 2019 at 15:51):
I'm running into a problem compiling a HAPI Service using HAPI 4.0.1 using OpenJDK 11 that wants to make use of FHIR R4 and needs to use javax.xml.namespace.NamespaceContext. The compile error is: The package javax.xml.namespace is accessible from more than one module: <unnamed>, java.xml
I've tracked it down (I think) to the the dependency chain: hapi-fhir-structures-r4-4.0.1.jar which depends on ucum-1.0.2.jar which depends on xpp3-1.1.4c.jar which defines javax.xml.namespace.QName. This conflicts with javax.xml.namespace package defined in JDK 11.
The xpp package is only used in the org.fhir.ucum.DefinitionParser class to parse UCUM definitions as far as I can tell.
I'm not sure why R4 structures is using this, it isn't found in STU3 or DSTU2 structures.
@Grahame Grieve Can you explain what ucum is used for in R4 Structures?
Keith Boone (Oct 09 2019 at 15:53):
For what it's worth, excluding the XPP artifact resolves the compile issue, but I'd like to understand better what functionality I'm effectively disabling when I do that.
Keith Boone (Oct 09 2019 at 15:58):
Also shows up as a depenency in org.hl7.fhir.validation (4.0.0) and hapi-fhir-validation (4.0.1), so a similar question there, what is XPP used for (what will I be disabling)
Grahame Grieve (Oct 09 2019 at 19:41):
the validator uses UCUM.
Grahame Grieve (Oct 09 2019 at 19:41):
Is this a version issue that the ucum code needs updating? because I use XPP in other places too
Keith Boone (Oct 09 2019 at 20:36):
The issue is that XPP defines javax.xml.namespace.QName which is already defined by Java in its runtime library, and so will run into issues when trying to compile a project using it without a module-info.java. Ideally, XPP would just reuse Java's javax.xml.namespace.QName class, instead of defining its own, but that package doesn't seem to have had any maintainence for half a decade or more.
Keith Boone (Oct 09 2019 at 20:56):
I note that the APIs for QName are exactly the same, and so I think I can resolve this without reducing functionality by removing that package from the XPP library, excluding that dependency from the build via Maven, and adding my patched library. I'm going to check this out to see if it works.
Grahame Grieve (Oct 10 2019 at 04:13):
@James Agnew I'm not following all this. Why hasn't this come up before? Do we need to clone XPP and sort this out? Wouldn't this be a problem for other users of XPP?
Keith Boone (Oct 10 2019 at 13:58):
I suspect the reason this hasn't come up before is b/c there were workarounds for it in Eclipse prior to 2019-06 release, where you could "import" the JRE libraries using classpath instead of via Module, but that capability no longer exists since that release. And so the only way you'd come up with it is if: a) you recently upgraded eclipse, and b) are using java XML and XPath libraries to do other work in your services b/c you are dealing with non-FHIR XML content.
Grahame Grieve (Oct 11 2019 at 01:59):
so I use xpp a lot. Maybe I should clone the code so that this isn't a problem anymore
James Agnew (Oct 11 2019 at 02:18):
I wonder if we could work around this by using xpp3_min instead. It doesn't bundle the javax.xml class (which is definitely the issue here). JDK9+ uses the new module system and does not like people bundling stuff like that in random JARs.
XPP is not likely to ever be adapted to modern Java, as far as I can see the last release was 12 years ago.. The better long term solution might be to try to migrate to StAX but that also might be a lot of work. Trying xpp_min seems like the logical first thing to try.
Grahame Grieve (Oct 11 2019 at 02:19):
@Keith Boone can you try that? if AllR5Tests pass, then that'll work fine
Last updated: Apr 12 2022 at 19:14 UTC
