I'm curious, how large of a company did you work for such that you were able to easily upgrade your JDK version?
Because I worked at a fairly large tech company and every one of our applications required some amount of manual intervention beyond figuratively switching all the "7"s to "8"s. That's despite the fact that hardly any of them were doing anything particularly complicated, and absolutely none of them were doing anything involving hidden com.sun APIs. I think it's just a consequence of such a large build system.
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.
Because I worked at a fairly large tech company and every one of our applications required some amount of manual intervention beyond figuratively switching all the "7"s to "8"s. That's despite the fact that hardly any of them were doing anything particularly complicated, and absolutely none of them were doing anything involving hidden com.sun APIs. I think it's just a consequence of such a large build system.