Add `jakarta` classifier version of `jackson-datatype-jsr353` to work with new Jakarta-based JSON-P

[filip26]

Hi!
Do you plan to support Jakarta JSON Processing?

The JavaEE packages are now being maintained and developed by the Jakarta project and Jakarta JSON v2.0.0 has been released recently. Unfortunately, v2.0.0 is not backwards compatible with 1.x.x because of package name change. 

[cowtowncoder]

The main question would be that of JSONP API compatibility I suppose; in theory underlying implementation should be less of a concern I assume? Either way, it sounds reasonable that we should either upgrade existing module or offer a separate one, depending on compatibility concerns.

This might be something to bring up on dev mailing list:

https://groups.google.com/g/jackson-dev

[filip26]

Upgrading from javax.json-api to jakarta.json-api practically means only to change package name from javax.json.* to jakarta.json.*. API is the same, but the package change breaks backward compatibility.

[cowtowncoder]

@filip26 I am not really worried about change done here as much as question of how users' experience would be -- is the Java of the JSON-P API itself changed? That would mean that any code written against API would be incompatible.
And if that is the case, that would be major breaking change and probably requires adding a new module, keeping both old one and new around for a while (to let users migrate from old to one).
That's not a huge problem (4th module for this repo) just slightly more maintenance.

I may have misunderstood change of course; I didn't think J2EE/J2SE API packages typically changed in this manner.

[filip26]

Oracle does not maintain Java EE anymore and decided to give away the rights for Java EE to the Eclipse Foundation. But the Eclipse Foundation legally had to rename Java EE packages because of Oracle's trademark on Java.

The 2.0.0 release is the first release of the Eclipse project for JSON-P under jakarta.json.* package namespace. It is part of Jakarta EE 9.
Jakarta JSON Processing (JSON-P)

As far as I know there is no other change in JSON-P API except re-packaging. My project Titanium JSON-LD uses JSON-P heavily, 1600+ tests, and there were no issues after changing package name in all sources.  (e.g. javax.json.JsonArray is now jakarta.json.JsonArray)

I understand your concern. You can add a new module and maintain both modules for the transition period. Or you can do a major release and maintain two version branches.

I'm happy to help.

[cowtowncoder]

@filip26 Thank you for the context: I have no objection to changes per se obviously, but want to understand full ramifications.

So, the requirement for downstream projects to change their sources and recompile may sounds like a small thing but is actually rather drastic change for transitive dependencies. That is, if you control code that uses JSON-P directly it is a small change, easy to make; but if you are in the middle, it becomes a gnarly problem.
This would seem like a challenge for frameworks, in particular; say, Spring folks.
And it does kind of break the whole "Standards are important because they guarantee interoperability" approach: it looks almost like JSON-P was effectively forked as "old" and new variants are neither source (need to change import statements) nor (in particular) binary compatible. :-/

[moquinr]

An artifact using the new coordinates (jakarta.json:jakarta.json-api) had been created for version 1.x and they still contain the javax.json package names. The 2.x versions change the package names. According to semantic versioning standards, a major version change is used when breaking interface changes are introduced. So this was handled properly in the Jakarta project, albeit it is still a small hassle (though very easy to do a find and replace on the package names.

Unfortunately, the thing the Jakarta project got wrong (and this drives me crazy to no end) is that they made the module names inconsistent with each other. For example, the wrong module name is included in the module-info of this project for javax.json (it was set as java.json in the json-api jar). I'm going to write an issue for it because it's breaking my project which is using this jar.. though super simple and easy fix.

[cowtowncoder]

Yeah, this is a major PITA. For Jackson, jax-rs-providers and jaxb-annotations module now dual-publish with regular (old -- for backwards compatibility) and new alternate one with "jakarta" classifier: this starting with 2.12.0.

Not sure what to do with JSON-P module: I suspect similar approach could work.
But at the same time, I also wonder how widely this module is even used and whether instead it should be deprecated and moved out of repo.

[moquinr]

I really like the fact that there is an integration between Jackson and the Java JSON libraries. I feel like maybe the same argument could be made for upgrading the package names in a new release of the module. If there aren't a lot of people using it, then there aren't many people it would inconvenience or irritate... :) At least if I interpreted your last statement correctly!

[cowtowncoder]

@moquinr I am a big proponent of interoperability, and hope to help it.
I probably should have formulated my comment above better: I'd like to have a better understanding about what components users do use, which they don't, and it is often hard to gauge. So feedback helps to know there are users who care. So I appreciate all feedback here!

[moquinr]

No problem, I don't want you to feel that your efforts are appreciated or useful! :) I am trying to stick with the new java JSON APIs but I appreciate being able to use a library like Jackson as the implementation. Thanks for being so quick on addressing this issue.

[fwiesweg]

@cowtowncoder When you have decided how to handle the issue and need a hand to actually implement it, please let me know. I just tried to migrate our software stack to the jakarta.* namespace, too, and got stuck on the jackson jsr-353 module, and I'd be glad to help resolve this quickly :)