-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for both javax & jakarta versions of JAXB in the same [Java SE] classpath #263
Comments
with jaxb, they can co-exist on the same classpath as long as they use jaxb-ri. Ie in Metro, the problem there was xmlsec dependent on javax with GlassFish having jakarta. The solution I used was to repackage javax versions in an extra artifact (see here). Another option I used in a different project is to use artifacts from also note that tooling now supports usage of old namespace in schema binding files, so even though one should update them to jakarta xml ns, he is not required to do so. (see the ri release notes) |
If I understand correctly, repackaging javax versions allowed those apps to have both in the classpath. That works but in my ideal world as a library I don't want to force people to change their existing dependencies to avoid this clash. Ideally my library could adopt jakarta JAXB and that wouldn't come with caveats like "you must also change this dependency / javax JAXB implementation ..." and if they didn't read that in release notes then the app breaks. Forcing people to change their existing javax JAXB implementation and/or dependencies is a really big ask for a library.
I don't understand how that avoids the clash for If there was a bundling of |
No. Take Metro as an end-user app built on top of JAXB with a dependency on Santuario which also uses JAXB, yet the former was updated to jakarta while the latter was not. GlassFish, like few other servers, is a consumer of Metro which does not (and should not) care about Metro-specific needs and dependencies. So in order to resolve that, Metro has both versions of JAXB on its classpath; packaging all Santuario's dependencies (including JAXB for javax package namespace) into an extra jar/artifact is just a minor detail which makes it easier for users to consume it ie in non-maven world, say ant (which is btw very often not being taken into account) and which also resolves OSGi problem with slf4j library required by Santuario.
JAXB as all other specs needs to live with the decisions made by the community now a days. Decision made was to invent some "transformer" which, when put on the classpath, does all the magic and in the end makes this transition easier. I personally have never believed the transformer approach is the way to go in pure Java SE world and I expressed that few times, yet I can agree it can help vendors at the platform level (app servers/EE managed environments). Unfortunately, SOAP stack as well as XML world as such is seen by many as a legacy technology not being used outside of the container these days, which EE platform vendors does not have to implement (as SOAP is optional), JAXB was part of Java SE for a long time, so the input from these ends is not being taken into account as seriously as it should. It is also very important to note that I believe all jakarta apis are suffering from this, not just jaxb.
the bigger picture of what this bom says would be similar to the one here from around a decade ago - basically the bom exports two streams of artifacts: internal ones targeted for developers under the ...so in the other project of mine, I used
no, I'm not aware of such artifact. That does not necessarily mean there is none. IMHO that would be the easiest, yet also the worst solution to this problem. Another probably slightly better alternative would be to let jaxb-ri and/or moxy artifacts include the runtime for jaxb2 in their own artifacts (like what did the jaxb-ri to support JAXB1 and JAXB2 back in EE 5/6/7 days) |
I mean apart from Java EE 8 versions of those artifacts obviously, which are supposed to be the same as Jakarta EE 8 ones. The mapping is shown at https://wiki.eclipse.org/Jakarta_EE_Maven_Coordinates, versions differ in the micro number (so for jaxb it is 2.3.2 vs 2.3.3) |
Thanks Lukas for all the answers, I really appreciate it.
I see the conflict on
I'm interested to understand why do we say this would be the worst solution? They are 2 incompatible API's/modules with the same maven groupId/artifactId (so for Java SE this is a major problem - EE providers can work around the problem but in Java SE we can't get around it without republishing the API artifact). I understand it would be bad for myself or every library to produce their own maven GAV artifact for That is, a different maven artifactId removes the problem for Java SE users but doesn't really make it harder for any EE runtime providers so I don't see why this is the "worst" solution?
Right, I get that. To state the obvious, that is going to hurt all the Java SE apps with third party libs depending on javax.xml.bind (Sardine, PdfBox etc).
Just to say my library does care. In fact virtually all my open source libraries are now Java 11 with module-info and that was one of the things that made me look at this "upgrade" to jakaka jaxb.
Yes although I think with JAXB it is going to hurt a lot more relative to the likes of servlet & persistence as an application will typically have one core implementation of servlet or persistence where as with XML/JAXB there is going to be lots of Java SE third party libraries that use "XML binding". It's all those third parties in the classpath in Java SE that makes it desirable to support both versions in a Java SE classpath. Anyway, as a Java SE library using JAXB I'm pretty confident that upgrading to Jakata JAXB is effectively a breaking change for Java SE applications unless someone releases the API with a different maven groupId and artifactId (which is what is required in order to support having both javax and jakarta versions of JAXB in the same Java SE classpath). |
Just to add - Artifacts using JAXB API (5,251) ... according to https://mvnrepository.com/artifact/javax.xml.bind/jaxb-api/usages |
since: <!-- some things need javax.xml.bind -->
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.3.2</version> <!-- javax version -->
</dependency>
<!-- runtime for javax -->
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
<version>2.3.6</version>
</dependency>
<!-- other things need jakarta.xml.bind -->
<dependency>
<groupId>jakarta.xml.bind</groupId>
<artifactId>jakarta.xml.bind-api</artifactId>
<version>4.0.0</version> <!-- jakarta version -->
</dependency>
<!-- runtime for jakarta -->
<dependency>
<groupId>org.glassfish.jaxb</groupId>
<artifactId>jaxb-runtime</artifactId>
<version>4.0.0</version>
</dependency> is valid configuration, what benefits would another deployment of One could then also be asking: if jaxb/xml binding can do this, why json processing and/or binding can not? They are also usable in pure Java SE, so the consistency is another point (actually introduction of the parsson project allowed similar support for co-existence of javax/jakarta runtimes for jsonp but not for jsonb). I do get your point, yet I think current artifacts and set up provide good enough while also (relatively!) cheap to maintain transition path from Java SE 8 up to the latest SE 18/19 - be it direct transition from the javax to jakarta or step by step through SE 11 where jaxb-api:2.3.2/jakarta.xml.bind-api:2.3.3 more or less correspond to the version removed from Java SE at that time (the tricky part in this step-by-step move can be figuring out the right combination of activation api/runtime but that should not matter as long as one does not require handling of specific mime-types (ie SOAP stuff, mail attachments)). |
Well I would say little benefit. To be clear, that is not what I am asking for. What I'm asking for is a different gId/aId for the Jakarta JAXB API ... the That is, as a library maintainer, the library has no knowledge nor control over an Applications use of Javax JAXB (the app classpath). If the library upgrades to Jakarta JAXB and hence now has a dependency on
For devs controlling the entire application classpath that is probably reasonable (as they can use the different gId/aId provided by As I see it, |
Edit: ... Currently we can't support both javax & jakarta versions of JAXB in the same classpath. This looks like a migration issue for library developers.
As a library developer with a test classpath/module-path dependency on JAXB I'm looking to bump that from
javax.xml.bind
tojakarta.xml.bind
.However, applications often at the moment still have some dependencies using
javax.xml.bind
- it's going to take time for all the dependencies to update tojakarta.xml.bind
(and as a library author I have no control over what apps depend on and how quickly other libraries will update to jakarta jaxb).As the maven groupId and artifactId are the same for both
javax.xml.bind
andjakarta.xml.bind
, we can't support both the old and the new versions of JAXB in the classpath at the same time. I believe we are going to want to support both versions of JAXB during the transition phase as apps and libraries update to jakarta JAXB.That is, we can't have the below, as the only difference is the version, the maven groupId and artifactId is the same.
This makes me think this is close to a catch 22 situation. Libraries can't update to
jakarta.xml.bind
[4.0.0] without breaking any apps that have a dependency onjavax.xml.bind
[2.3.3]. Apps can't update tojakarta.xml.bind
until all their library dependencies have updated.Upgrading to jakarta JAXB requires a "big bang" style upgrade where absolutely all JAXB use needs to go from javax to jakarta in that single upgrade as both jakarta and javax JAXB can't co-exist on the classpath. This is going to be tough for larger apps that have more and older dependencies.
Is there thought to releasing the new
jakarta.xml.bind-api
with a different maven artifactId in order to support bothjavax.xml.bind
andjakarta.xml.bind
in the classpath/module-path while libraries and apps go through a transition phase?The text was updated successfully, but these errors were encountered: