Bumped to SpringBoot4, SpringFramework7 and JDK17 - same as #705, but with signed-ff commits

[jacekbilski]

The content is the same as in #705, see the discussion there. The only two changes are: the commits are now properly signed-off and I've rebased it onto main.

[lehphyro]

Hey guys, are you planning to merge this soon? It's blocking Spring Boot upgrades because of Jackson 3 breaking changes.

[jacekbilski]

I wish I could say more. I believe that @stromner-stralfors and I have made all the necessary changes, the code works for me™. Anything beyond that is in the hands of the maintainers.

[lbenedetto]

@duglin Can you answer if this is something you (the maintainers, not specifically you) will be working on?

[duglin]

@lbenedetto let me poke some folks

[duglin]

Seems reasonable to me, however, with such a large number of files changed (and some being more than just a version number change), let's wait for @Cali0707 to verify that nothing seems off.

[Cali0707]

yes currently taking a look here (started yesterday, but lots of changes...)

[Cali0707]

Hey @jacekbilski thanks for all the much needed hard work to modernize this SDK!

I think to make these changes more releasable we need to split this up into a couple more incremental PRs/releases:

1. Let's mark http/restful-ws's public classes as @Deprecated(forRemoval = true). As part of this, we should copy the code into http/restful-ws-jakarta and permanently switch the javax to jakarta namespacing. We do not want to remove the restful-ws-jakarta support in 5.0 (and can't remove either currently as neither module is actually marked as deprecated, despite the commit comment saying they are).
2. Make a 4.1.0 release after step 1 is merged
3. Bump to Java 17 baseline and apply the language modernization changes (version bump to 5.0.0-SNAPSHOT)
4. Drop the restful-ws module and update restful-ws-jakarta to Jakarta REST 4.0
5. Apply the HttpHeaders defensive copy fix and the @Nullable annotation switch (these are both needed for Spring Boot 4 forward compatibility), but keep compiling and testing against Spring Boot 3.x. This way users on both 3.x and 4.x can use the module. I thinking moving from the current 2.x all the way to 4.x in one go is too aggressive and will make it so some users can not use this.

I don't think we need to bump to Jackson 3 currently, as there is still a large portion of projects on Jackson 2. Additionally, let's stick with JUnit 5 for now to help keep the scope of changes smaller.

If you are able to start working on pieces of this in separate PRs, ping me and I'm happy to try to quickly merge them and move this process along!

[jacekbilski]

Hello @Cali0707,

I'll start working on those things soon.

One note, current 4.x version is working perfectly with Spring Boot 3, I'm using it that way since over a year. So the jump to Spring Boot 4 is not that big.

[lehphyro]

Hey @Cali0707, Spring Boot 4 upgrades Jackson which renames packages to tools.jackson, not upgrading it means users will be forced to use the deprecated compatibility module spring-boot-jackson2, see https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-4.0-Migration-Guide#upgrading-jackson

[Cali0707]

@jacekbilski @lehphyro I appreciate the points you are raising. My strong preference for not bumping these all now is because we have lots of different usages in different projects with different sets of dependencies.

Let's:

1. Do a release with java 17, and the different fixes (as I mentioned above), using jackson 2. We can indicate that this will be the last release on jackson 2.
2. We can do a follow up release with spring 4 and jackson 3. This should hopefully help the different consumers of this repo with time to migrate (and again, even if things are working, jumping from 2.x to 4.x is a very large jump - we really should only go one major version at a time)

[jacekbilski]

@Cali0707 As we're anyway providing Jackson support in the form of json-jackson module, maybe providing two, one for Jackson 2 and one for Jackson 3, would be an option? I cannot tell just yet how difficult or time consuming would that be, I'll be looking into this. But this way we could provide something for everyone.

[Cali0707]

@jacekbilski we could definitely do a dual package approach for jackson 2/3 (and IMO deprecate the jackson 2 package to indicate to people to move off it). I think this is a great approach

As with everything else here I'm fully on board with modernizing the dependencies/packages in this SDK, I just want to make sure that we are upgrading in a way where it is easy for all the SDK consumers to incrementally update, and where we are communicating what is being deprecated in releases before we remove support.

[Cali0707]

@jacekbilski are you okay with the plan we've discussed here? Mind opening issues for the different steps so that we can close out this PR and start tackling/releasing bits of this incrementally?

[jacekbilski]

@Cali0707 Fine by me. I'll open new issues and close this PR once I'll start working on it.