Hibernate Modules deprecated in Jackson 3.0?

[jim-jobcase]

Apologies if I missed something, but I've tried going through the Jackson 3 releases notes and various JSTEP posts, but I'm confused about the status of the Hibernate modules and Jackson 3.

Looking at the source code the jackson-datatype-hibernate module seems to be limited to the 2.x series, with no version for 3.x.

Are these modules no longer needed/supported for Jackson 3? Or are they something where a follow-up release will add support later? If there's a thread/post I can read to get caught up on this, I'm happy to do that - I would just appreciate a link, since I'm struggling to find clarification here.

Thanks in advance for any pointers or guidance you can provide!

[pjfanning]

The hibernate modules are not widely used and it was decided to wait to see if there was a need to port them to support Jackson 3. Maybe we'll do something if there is enough interest. I am a bit surprised at how many people are looking at Jackson 3. It is a big set of changes and Jackson 2 is not being abandoned. I have no plans to switch away from Jackson 2 in my apps in near future.

[jim-jobcase]

I can't answer for everyone, but I'm looking at it because of Spring Boot 4 - since I need to make various platform updates to support that, evaluating a move to Jackson 3 at the same time is convenient. So far it all seems to work - there might still be risks ahead for us, but we figure most effort and attention will be put there so why not get a jump start on the effort to move? It might take a couple years for us to fully adopt it across all our services, but we're trying to be ready for the future.

Thank you for letting me know about that. Please consider this a vote/request for Hibernate module support, as we do have RestController interfaces that return database entities, and those might leverage lazy loading.

Thank you again!

[cowtowncoder]

Ok the process is as follows: when converting modules to Jackson 3 namespace started, we realized some modules were unmaintained (no active owner). This includes Hibernate module and JSON Schema module. Since no one stepped up (when asked on mailing list), proposal was to leave these modules as-is, published for 2.x, but mark as deprecated:

https://github.com/FasterXML/jackson-future-ideas/wiki/JSTEP-9

further discussion:

FasterXML/jackson-future-ideas#76

reached same conclusion. It is too bad community participation was somewhat limited here; but as far as I could see, no one seemed to care about Hibernate module(s).

This is not to say Hibernate module could not be migrated -- that is, the decision was NOT "just kill them" but rather "unless someone steps up, 3.0 versions won't happen" -- but for that to happen we'd need to find a maintainer.
If and when that happens I am happy to help with conversion (and handle release process). But I don't have time or interest to drive the work.

NOTE: if conversion (creation of 3.x branch, making changes to work with core Jackson 3.0 internal API) was to occur relatively soon, we could publish 3.0.0 versions. The only (?) thing missing from 3.0.0 would be inclusion in jackson-bom v 3.0.0.

[cowtowncoder]

I realized Hibernate module README (https://github.com/FasterXML/jackson-datatype-hibernate) did NOT actually mention deprecation -- I added it, although may need to make more prominent.

[pjfanning]

I can have a look at supporting Jackson 3 but it will be a few days or more until I get the chance.

[jim-jobcase]

Thank you for the references, and highlighting the deprecation note in the README. I missed that JSTEP post, and I don't normally read the discussions area of GitLab unless I have a problem. And many thanks to @pjfanning for seeing if support is possible.

As a "poorly engaged" developer who only digs into this project as we hit issues, there are two places that would have helped raise the visibility of this, and at least to me would help advocate for sponsorship, or at least push to spend time on PRs providing help:

1. Include the deprecations in the Jackson 3 migration guide
2. Add @Deprecated to the modules and their constructors with a message similar to "deprecated in 2.(n), will be removed in 2.(n+x) and 3.(y)".

Obviously you know this project far better than I do so I apologize if those seem like infeasible changes or efforts, or would cause you more problems.

[cowtowncoder]

As a "poorly engaged" developer ...

Just as clarification: I did not mean to imply you are one at all!
I know our outreach was not very effective.

Thank you for suggestions on improved mark up to share the knowledge.

We'll have to think of best ways to do this: Deprecation notice on 2.x sort of depends on whether deprecation remains etc.

[jim-jobcase]

No implication received! It was an attempt at self-deprecation, given that I fall into most of the community that silently use without contributing to the channels for feedback you provide.

Thanks again to you and all the other maintainers for this project!