Cover all removed classes in the migration document [SPR-16282]

[spring-projects-issues]

Philippe Marschall opened SPR-16282 and commented

Several classes removed in version 5 are not deprecated in version 4. This makes upgrading unnecessarily hard.

Among those are NativeJdbcExtractor and the org.springframework.beans.factory.access, org.springframework.context.access and org.springframework.ejb.interceptor packages.

Unfortunately none of those are mentioned in Upgrading to Version 5.0

---

Referenced from: pull request #1620

[spring-projects-issues]

Philippe Marschall commented

add PR

[spring-projects-issues]

Juergen Hoeller commented

Have you been specifically hit by anything here? I agree that those should be covered in the migration document.

Not marking those as deprecated was rather intentional since they aren't really deprecated for the goals and purposes of the Spring Framework 4.x generation. We just chose to cut down Spring Framework 5 accordingly, like we did with the Portlet MVC module (which isn't deprecated in 4.x either). I know, that's a subtle distinction and can be argued either way, but I'd prefer not deprecating such artifacts which don't have a direct replacement in 4.x for the infrastructure support range there (which includes Java EE 5 baselined servers such as WebSphere 7, with no CDI and therefore no Spring-CDI bridges being applicable, as well as old Oracle 9i JDBC drivers).

For NativeJdbcExtractor specifically, see the discussion in #19234.

[spring-projects-issues]

Juergen Hoeller commented

I'm considering this as resolved from the perspective of having covered all removed classes in the migration document, with a bit of rationale given there. If there's anything specific to add, I'm happy to revise that section even further.

[spring-projects-issues]

Philippe Marschall commented

We have been hit by org.springframework.beans.factory.access, we have an annotation based Spring EJB bridge similar to org.springframework.ejb.interceptor.

For the nativejdbc package people on SO have been hit by this https://stackoverflow.com/questions/47397238/replacement-for-jdbc-support-nativejdbc-remove-in-spring-5/47397593

Personally I would be fine with just mentioning it in the migration document but deprecating gives you "IDE support". It allows you to clean up everything beforehand.

[spring-projects-issues]

Juergen Hoeller commented

It's a fine line... We had complaints before when people were forced to use deprecated methods (without a direct replacement) for their particular purposes. Also, deprecating them now in 4.3.14 might bug quite a few of long-time 4.3.x adopters whereas not too many 4.3.x->5.0 upgraders are likely to go to 4.3.14+ first, so not even noticing those deprecations. In that sense, I find the migration document much more important.

[spring-projects-issues]

Philippe Marschall commented

Fair enough, I guess you get complaints no matter what you do :)