Yeah the reality of the situation is that it's never as straight-forward as just recompiling with the latest JDK.
From my experience it wasn't generally code written in-house that'd cause problems (but sometimes it was), it was dependencies and transitive deps that required the older JDK (sometimes they relied on old bugs or old tooling, sometimes they just couldn't be recompiled on the new JDK for whatever reason).
Build tools that relied heavily on JVM internals often couldn't upgrade for some time. Third parties integrating with your software and the new JDK brings a slight change in it's SOAP/XML/ser-deser stuff etc.
That said, Java has been the best at backwards compatibility that I've tried, given it's popularity, and most of the pain was in the early days (like anything I suppose, see the Javascript world atm). Microsoft's offerings probably do backwards compatibility well, but then you get all the rest of the technical- and wallet-pain that that environment brings with it.
From my experience it wasn't generally code written in-house that'd cause problems (but sometimes it was), it was dependencies and transitive deps that required the older JDK (sometimes they relied on old bugs or old tooling, sometimes they just couldn't be recompiled on the new JDK for whatever reason).
Build tools that relied heavily on JVM internals often couldn't upgrade for some time. Third parties integrating with your software and the new JDK brings a slight change in it's SOAP/XML/ser-deser stuff etc.
That said, Java has been the best at backwards compatibility that I've tried, given it's popularity, and most of the pain was in the early days (like anything I suppose, see the Javascript world atm). Microsoft's offerings probably do backwards compatibility well, but then you get all the rest of the technical- and wallet-pain that that environment brings with it.