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 :)

[cowtowncoder]

@fwiesweg @moquinr @filip26 I think that in this particular case it'd probably be better to simply duplicate code, instead of using more complex scheme like post-processing and Maven classifiers (which has been used with jaxrs providers). So:

• leave jsr-353 (folder) / jackson-datatype-jsr353 (artifact id) / com.fasterxml.jackson.datatype.jsr353 (Java package and Module root) as-is
• Add, say, json-p / jackson-datatype-jsonp / com.fasterxml.jackson.datatype.jsonp equivalents, just copy and relocate.

This new artifact should be officially part of 2.13, but I could release a preview version as part of 2.12.x once there is something to publish.

[fwiesweg]

For the fun of it, I just copied over the postprocessing/classifier solution from jaxrs [1] because it really didn't look that hard and ran our applications small test suite over it. It appears to have just worked. I used the 2.12.1 release of jackson for it because I didn't feel like collecting all the 2.13 artifacts for a draft, but it should work for the new version just as well.

All that needs to be done to use the jakarta version is to add a <classifier>jakarta</classifier> in the dependency-section of the pom.xml, no further adjustments needed.

I'll open a pull request in a second so you can examine the draft.

[1] https://github.com/FasterXML/jackson-jaxrs-providers/blob/master/json/pom.xml

[cowtowncoder]

@fwiesweg ok that's fine as well, and one benefit is that if we can make this work quick, it would even make it in 2.12.2 release! So PR could/should be based on 2.12.

From quick look, looks good. Not sure if there is need for "no-metainf" variant at this point, so could leave that out (has not been requested and although could be theoretically useful there is an issue with that as @GedMarc pointed out -- does not filter out service declaration from module-info.java.

[cowtowncoder]

@fwiesweg As per my comments on PR, looks good & would be happy to merge -- but need CLA (unless I have one in which case I just need to locate it by name) first. If and when I get it, could still merge it to be included as part or 2.12.2 I plan to release ASAP.

[fwiesweg]

I'm waiting for approval from higher up, sorry for the delay. I'll try to move it forward faster. If you're lucky you'll have it in your hands later this day.

[fwiesweg]

Should be in your inbox.

[cowtowncoder]

Merged and 2.12.2-SNAPSHOT published; same for jackson-bom (wrt added "jakarta" variant).
If anyone can verify that this works, that'd be great (no integration tests yet, would be good to add to jackson-integration-tests); I am planning to release 2.12.2 real soon now.

[fwiesweg]

I tried the artifact from the sonatype repo and it works for me.

[cowtowncoder]

Sounds good: hoping to release 2.12.2 tonight or tomorrow.