Classpath et version de librairies externes

Hello,

J'ai une application qui dépends d'une librairie A.jar et d'une librairie B.jar. Le problème est que la librairie A dépends également de B.jar, et l'encapsule dirèctement dans le .jar.

Du coup, lorsque je lance mon application, la librairie B me renvoi un message comme quoi il détecte deux version.

Dans de tels cas, je sais qu'il utilise la première qu'il trouve... Perso, je souhaiterai que mon application utilise la version que je lui indique, et que A utilise la sienne.

Est-ce possible d'une quelconque manière ? Comment régler ce type de problème ?

Merci d'avance!

A moins de créer ton propre classloader, ce n'est pas possible.

La solution la plus simple pour réaliser cette opération est de "repackager" la librairie B dont dépend A (en préfixant par "a.dependency." par exemple).

Ainsi, les deux librairies seront différentes, et chacun utilisera la sienne sans empiéter sur l'autre.

Attention toutefois à ce que la licence de la librairie autorise un tel repackaging si elle ne vous appartient pas.

Créer son propre class loader... Je ne suis pâs familier avec ca: ca prends du temps ? Est-ce que ca peut impacter les performances de l'application ?

Merci en tout cas de ta réponse :)

Citation:

---

Envoyé par vinzzzz

Créer son propre class loader... Je ne suis pâs familier avec ca: ca prends du temps ? Est-ce que ca peut impacter les performances de l'application ?

Merci en tout cas de ta réponse :)

---

ca prend du temps, c'est galère, et ca va surtout impacter votre code. C'est le principe des plugins avec isolation entre les plugins, mais ca nécessite du coup que, chaque vois que dans votre code principal vous voulez instanciez des trucs dans A, vous passiez soit par une factory fournie par A, soit par le classLoader, sa méthode forName, les Constructeur par reflexion. Bref dans le premier cas, il faut une libiraire qui est déjà prévue pour ça (système de plugin), ce qui n'est vraissemblablement pas le cas ici, dans le deuxième cas, il faudra à chaque fois 10 lignes de code pour faire l'équivalent d'un "new MachinDansA();"

Je maudit à chaque fois les auteurs de librairies qui ont l'idée "lumineuse" de packager dans leur jar une librairie tierce :weird:. Doivent pas connaitre des masses les grosses applications eux. Bref, personellement, la solution que je trouve la plus facile en général:

ouvrir A.jar (avec winzip, file-roller ou autre)
retirer toutes les classes provenant de B
sauver le jar

et j'obtiens au final un A.jar qui utilisera le B.jar que je lui fournirais et rien d'autre !

Citation:

---

Envoyé par tchize_

Bref, personellement, la solution que je trouve la plus facile en général:

ouvrir A.jar (avec winzip, file-roller ou autre)
retirer toutes les classes provenant de B
sauver le jar

et j'obtiens au final un A.jar qui utilisera le B.jar que je lui fournirais et rien d'autre !

---

Sauf que la librairie A qui utilisait B peut ne plus marcher puisque B est d'une version différente ;)
Mais c'est sur que c'est mieux d'embarquer 1 seule fois B...

Citation:

---

Envoyé par hwoarang

Sauf que la librairie A qui utilisait B peut ne plus marcher puisque B est d'une version différente ;)
Mais c'est sur que c'est mieux d'embarquer 1 seule fois B...

---

Si il y a incompatibilité entre les deux versions (ce qui n'est pas certains, ici le problème est la duplication de la libiraire), il faudra choisir:

soit utiliser la vieille version de B uniquement,
soit ne pas utiliser A.