Request for distinguishing acronym for "Jakarta XML Binding", different from JAXB

[cowtowncoder]

TL;DNR; to distinguish "old" Java XML Binding api -- JAXB -- from new Jakarta XML Binding api -- not JAXB -- some distiguishing Id would be useful. Not sure what: JAKB? JAKXB? JAXB3?
(I kind of like "JAKB" even if I initially added it as a joke).

Longer story:

Now that there is a major breaking version change in this space -- old "JAXB" not being binary or source compatible with new one, due to package (java package, maven group) change -- it is necessary for many intermediate packages to indicate which java XML binding api they implement.
In my case this is for Jackson JAXB annotations package:

https://github.com/FasterXML/jackson-modules-base/tree/master/jaxb

The change itself should be quite mechanical, although now there is need to support 2 different (if similar at many levels) APIs and that cannot be done with just one package. Solution there is to do something like:

• Use one source package, post-process bytecode and metadata with Maven shade plugin, use classifier for resulting package (attempted currently with "jakarta" classifier, see f.ex https://repo1.maven.org/maven2/com/fasterxml/jackson/module/jackson-module-jaxb-annotations/2.12.2/)
• Fork package into two: old and new

Former has the benefit of just a single source codebase and may work initially. Latter has the downside that it literally doubles code to maintain (until old one can be deprecated in distant future), but upside that it Actually Works and will keep working when new Jakarta XML Binding API possibly changes (presumably old JAXB will not).

So I am thinking of going with the latter route for Jackson 2.13: but if so, will need a new name.
So jackson-module-jaxb-annotations needs to be come something else. If so, I would like to follow a well-known pattern: perhaps jackson-module-jakb-annotations

So: I think there should be acronym for Jakarta XML Binding, different from "JAXB" (which refers to old Java XML Binding).

But what should that be?

[lukasj]

there is need to support 2 different (if similar at many levels) APIs and that cannot be done with just one package

It depends on what exactly you want to support and what price you are willing to pay for it. Since APIs as well as implementations are in different packages, one should be able to:

• depend on javax.xml.bind:jaxb-api (old javax, CDDL+GPL-1.1 licensed) and jakarta.xml.bind:jakarta.xml.bind-api (new jakarta, EDL 1.0 license)
• depend on com.sun.xml.bind:jaxb-impl (runtime for javax) and org.glassfish.jaxb:jaxb-runtime (runtime for jakarta)
• update affected codebase with if (isJavax || isJakarta)...

this way one should be able to avoid duplicating the code and support even JPMS properly - jaxb-impl and jaxb-runtime have different module names and dependencies (well, I can see small issue in "old" jaxb runtime but I think I'll manage to resolve it in upcoming 2.3.4) - at the cost of bigger dependency tree and too many ifs in the code.

An alternative could be to define default, say jakarta namespace reader, and an alternative (javax) reader through some provider interface which if found by the default will be used instead. From end-user perspective, it will be up to him to pick up what he wants.

One point you are not considering is impact of JPMS - do you want/need to support it or not? The problem with "old" JAXB impl is that some of its artifacts are hard, if not impossible, to update for JPMS because of split package problems (not a problem if one uses/depends on artifacts with com.sun.xml.bind group Id).

I'm far from knowing how exactly this can be implemented in your particular case and what exactly you have to support, ie this won't work if you need xjc (should you need this, the best is to depend/use the new one only as it should be possible to use it to generate "old" javax references through it), so take that just as a suggestion.

I think there should be acronym for Jakarta XML Binding, different from "JAXB" (which refers to old Java XML Binding).

I've started using XMLB as a shortcut for Jakarta XML Binding. Do not take that as an official name, it's just that I'm trying to safe myself from typing :-) The only thing which should be taken as granted is that nothing with JAXB can be used (see guidelines) by projects governed by Jakarta EE.

[cowtowncoder]

Thank you for all the advice! And just to make sure, I am not asking about how to implement this so much for my use case -- which is unfortunately "branch" level; neither app code (where no one depends on library), nor platform code (jax-xx provider); but rather between those two layers.
This means that components in question will need to depend on (implement or use) types from JAXB/XMLB and then expose these to application code. There are definitely implications wrt JPMS and that is one more reason why I likely have to work 2 distinct components to cover before/after cases.

I guess implementing dual-handling could be possible in some cases, but there is a non-trivial downside of doubling dependencies and keeping old api around. This could be confusing to users, esp. since IDE auto-completion would now bring up 2 choices for all types.
Still, worth considering as the third option, beyond simple replacement or forking.

But if forking what I am hoping to figure out is the naming part, to try to reduce confusion to end users.
Especially when they try to navigate the changes to upgrade their favorite JA?-RS implementation (which I do not own or manage), which in turn will expose the new API (or not): which Jackson JSON provider do I need to use? Jackson has its own versioning schema, but one that is not aligned to Javax/Jakarta difference (it is not a J2ee or Jakarta implementation at its core). But J2EE/Jakarta distinction is a "secondary" variant for some of the components.

I hope this makes more sense: this is not an easy problem to necessarily explain.

Now, on naming idea: XMLB sounds like a potential name I could use. One caveat is that I will also need to think of similar counterpart for JAX-RS api and it would be nice if there was a pattern. But I can understand why this may be challenging.