Java Classloader - comment référencer les différentes versions d'un pot

Question

Ceci est un problème commun. J'utilise 2 bibliothèques A.jar et B.jar et ceux-ci dépendent de différentes versions du même pot.
Disons que lors de l'exécution je besoin THIS.x.x.x.jar

MY.jar   
     -> A.jar -> THIS.1.0.0.jar
     -> B.jar -> C.jar -> THIS.5.0.0.jar

Je peux compiler le pot spécifique (A.jar / B.jar) contre sa dépendance à l'exécution, mais j'ai de ne charger que la version 1. Laquelle?
Chargement seulement 1 dépendance (la dernière version) signifie que mon code sera probablement lancer des exceptions d'exécution si les bibliothèques ne sont pas rétrocompatibles (bibliothèques sont là rétrocompatibles là-bas?).

En tout cas je sais que quelque chose comme OSGi peut résoudre ce problème.
Je me demande quelle est la vieille façon de résoudre ce genre de problèmes ...

Merci beaucoup

Answer 1

« chemin Old » vous avez mentionné (et celui OSGI utilise certainement sous le capot) est d'installer votre propre ClassLoader pour les deux branches de vos dépendances. C'est ainsi, par exemple, les serveurs d'applications sont en mesure d'exécuter les deux versions anciennes et nouvelles de la même application dans la même machine virtuelle Java.

En savoir plus sur la hiérarchie classloader.

Dans votre configuration, la partie la plus délicate est le point commun, où les classes des deux branches se rencontrent. Ni les branches peuvent utiliser les classes chargées dans un autre. La façon de le faire fonctionner est de se assurer que les classes chargées par démarrage classloader (classes JRE) ou classloader de MY.jar sont transmis aux deux branches.

Answer 2

OSGi peut résoudre ce problème. Un faisceau de OSGi est rien de plus qu'un pot avec des versions détaillant de métadonnées supplémentaires. Un paquet a un numéro de version, et détaillera les numéros de version (ou des plages) de pots à charge.

Jetez un oeil à cet article d'introduction JavaWorld pour plus d'informations.

Pour résoudre ce sans moyens OSGi avoir à vérifier manuellement que vous compilez et exécutez avec des pots compatibles. Comme vous l'avez découvert ce n'est pas nécessairement une tâche triviale. Étant donné que les pots n'identifient pas nécessairement leurs versions, la seule façon de le faire pour enregistrer / comparer checksum ou signatures.

Answer 3

De nombreuses bibliothèques sont rétrocompatibles. Mais pas tous ..

---

L'ancienne est d'essayer de dépendre de une seule version.

Il est probablement plus sûr de compiler les deux avec la même version (dernière).
Au moins vous obtenez à la compilation des erreurs, au lieu des erreurs d'exécution.

Si nécessaire, vous pouvez modifier un peu votre bibliothèque qui fonctionne avec l'ancienne dépendance ...
Cela nécessiterait l'accès à la source ...

---

S'il vous plaît noter que la compatibilité de compilation ne garantit pas le comportement d'exécution correcte soit. Il est une étape, vous pouvez:

• lire le fichier WhatsNew pour la nouvelle version du pot
• Regardez sur Internet pour les utilisateurs ayant signalé des problèmes de compatibilité
• JUnits d'écriture
• comparer les codes dans les deux bocaux

Answer 4

Comme mentionné par KLE, l'approche par défaut est de dépendre de la version plus récente. Il n'y a aucune garantie, mais la plupart du temps, cela fonctionne. Probablement la meilleure façon (tout en étant un ballonnement) utilise OSGI pour obtenir dessus.

Answer 5

Pour consulter une caisse mise en œuvre "Oldway" base https://github.com/atulsm/ElasticsearchClassLoader

Ceci fournit une approche pour gérer les versions non compatibles en arrière de l'utilisation du client ElasticSearch.