问题
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.9to1.10 - spring:
3.xto4.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?
回答1:
Because ASM is a tool that operates on the Java byte-code. And the byte-code format changed to introduce new features. As such, you had to upgrade the tool to support the new byte-code.
Note, that software compiled with an older version of the JDK does not always work with newer versions of Java. For example, enum was not a keyword in early versions of the JDK.
回答2:
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.
来源：https://stackoverflow.com/questions/28228450/java-is-backward-compatible-but-why-we-need-to-upgrade-many-libraries-when-we-u