Java est rétro-compatible, mais pourquoi devons-nous mettre à niveau de nombreuses bibliothèques lorsque nous mettons à niveau jdk de 1.6 à 1.8?

Parce que ASM est un outil qui opère sur le code octet Java. Et le format de code octet a changé pour introduire de nouvelles fonctionnalités. En tant que tel, vous deviez mettre à niveau l’outil pour prendre en charge le nouveau code d’octet.

Notez que ce logiciel compilé avec une version plus ancienne du JDK ne fonctionne pas toujours avec les versions les plus récentes de Java. Par exemple, enum n’était pas un mot clé dans les premières versions de JDK.

ASM est une bibliothèque de bas niveau.

Il traite directement le code en octets Java (alors qu’une application “normale” laisserait simplement la JVM charger ses classes). Le format du code d’octet change de temps en temps et les versions plus récentes ne peuvent pas être utilisées par une machine virtuelle plus ancienne.

Messing avec JDK ou internes au format de classe n’est pas couvert par la compatibilité ascendante.

Il s’agit vraiment d’un cas marginal, et ASM est à peu près le seul exemple “populaire”.

Plus important encore (et plus courant), il existe toutefois de légers changements de comportement dans le code de la bibliothèque système. Donc, techniquement, votre application fonctionnera toujours, mais fera les choses différemment. La plupart du temps, c’est ce que vous voulez, car cela signifie une amélioration (par exemple, de meilleures performances), mais cela peut parfois causer des bogues pour vous.

Par exemple:

• le passage à la JVM 64 bits peut nécessiter plus de mémoire
• les changements dans la récupération de place peuvent entraîner des pauses inattendues
• l’inclusion d’parsingurs XML dans le JDK proprement dit nécessite des modifications au packaging ou à la configuration de l’application Web
• Les caractéristiques de mémoire et d’exécution de la chaîne # de Ssortingng changent complètement dans la révision JDK “mineure”
• sortinger une collection avec un comparateur personnalisé (implémenté de manière incorrecte) lève soudainement des exceptions qu’il n’a pas lancées auparavant
• L’appel de Thread # stop (Throwable) (ce qui n’était jamais une bonne idée et qui est obsolète depuis très longtemps) lève une exception UnsupportedOperationException depuis Java 8.
• Unicode mis à jour prend en charge la modification du comportement de sorting et de casse de certaines chaînes
• Changements dans la compilation des génériques
• Impossibilité d’étendre BitSet et d’implémenter Set en raison de nouvelles méthodes par défaut
• Changements dans le comportement d’arrondi
• Et beaucoup d’autres changements dans les API et BPI

Mais dans l’ensemble, l’histoire de la compatibilité des applications existantes est vraiment satisfaisante avec Java. Ils doivent en tenir compte pour tous leurs clients.