But then you are using a 1 year old framework (if you're lucky) that depends on a version of library X that is 2 years old that depends on a 3 years old library etc.
At the end of the chain you have a library that does low level stuff (bytecode instrumentation for example) and is a few years old. That is what may give you problems, and often the only practical solution is to update to a newer version of the framework, which can be quite expensive.
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.
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.
Interested to hear which Java API you use which requires special modification in order to be compilable on Java 8?
Usually most of this breakage is caused by the com.sun stuff which isnt public API.