Java is backward compatible, but why we need to upgrade many libraries when we upgrade jdk from 1.6 to 1.8?

Question

Recently, we upgrade the Jdk version from 1.6 to 1.8 in one of my Java project. But there are some compilation or runtime errors, so I have to upgrade some libraries:

• gradle: 1.9 to 1.10
• spring: 3.x to 4.x

That because they are using some early versions of ASM, but which supports jdk 1.8 only from 5.x

Java said it is backward compatible, but why the original versions of libraries can't work with jdk 1.8 directly?

Answer 1

ASM is a pretty low-level library.

It processes Java byte-code directly (whereas a "normal" application would just let the JVM load its classes). The byte-code format changes from time to time, and newer versions cannot be used by an older JVM.

Messing with JDK or class format internals is not covered by backwards compatibility.

This is really an edge-case, and ASM is pretty much the only "popular" example.

---

More importantly (and more common) though are slight behavioural changes in system library code. So your application will technically still run, but do things differently. Most of the time, you want that, as it means improvement (for example better performance), but sometimes it can cause bugs for you.

For example:

• switching to 64bit JVM can require more memory
• changes in garbage collection can lead to unexpected pauses
• inclusion of XML parsers into JDK proper requires changes to web application packaging or configuration
• memory and runtime characterics of String#substring completely change in "minor" JDK revision
• sorting a collection with a custom (incorrectly implemented) comparator suddenly throws exceptions it did not throw before
• Calling Thread#stop(Throwable) (which was never a good idea and has been deprecated for a very long time) throws a UnsupportedOperationException since Java 8
• Updated Unicode support changing sorting and casing behaviour for some strings
• Changes in generics compilation
• Inability to extend BitSet and implement Set due to new default methods
• Changes in rounding behavior
• And many others changes in API and BPI

---

But all-in-all the legacy app compatibility story is really good with Java. They have to keep it in mind with all their enterprise customers.