See https://wildfly.zulipchat.com/#narrow/stream/242838-Jakarta-EE/topic/Dependencies.20on.20JSON for background discussion.

Various WildFly modules integrate artifacts that compile against the EE 8 Jakarta JSON API and depend at runtime on an impl of it, but which don't expose Jakarta JSON to their users. They simply want to do things involving JSON as part of their internal implementation, and use Jakarta JSON and an impl thereof as a convenient way to do so.

Ideally such artifacts would produce versions that use an EE 9+ jakarta.* namespace variant of the JSON API, but whether or when they will is hard to say, particularly since those projects may regard the JSON use as an internal detail.

But for standard WildFly to move to EE 9 or later, we need to those artifacts to work, even though the standard Jakarta JSON API and impl in the server will use the jakarta.* namespace.

Proposed temporary (hopefully) solution is to:

1) Add a new 'internal.javax.json.api.ee8' module. (Name can be debated; main point is to emphasize it's 'internal-ness'.)
2) The 'javax.json.api' module becomes an alias to 'internal.javax.json.api.ee8'. (In WF Preview it remains as it currently is – an alias to 'jakarta.json.api'.)
3) If there's a way to mark 'internal.javax.json.api.ee8' as jboss.api=private while not doing that with the 'javax.json.api' alias, that would be nice.
4) Create a new module that provides a different impl of EE 8 Jakarta JSON. I expect this will need to be a complete different project from our regular one, e.g. https://johnzon.apache.org/. The reason for this is the way we integrate artifacts into our module.xml files won't work if we try and have two different artifacts in the system with the same maven groupId:artifactId.
5) Modules that use Jakarta JSON and that are in the category described here would change their dependencies to use the new modules.

There should be more discussion about this before implementation work gets going, as the right solution might differ quite a bit from the above. I wrote all the details above to serve as a rough illustration of the concepts but it needs more thought. For example the right solution for now, when std WF is EE 8 and WF Preview is EE 9 might differ from how it should work when std WF is EE 9+.