Jak masz te jary w classpath, to ich kolejnosc ustala jaka klasa bedzie wczytana - zawsze ta pierwsza. Osoby mowiace ze ten problem mozna rozwiazac za pomoca mavena / ivy po prostu nie wiedza o czym mowia - maven to tylko zarzadzanie zaleznowsciami i ich wersjami, ale ostatecznie jak masz 2 wersje tej samej klasy w cp to jest to blad i tyle.
Poza tym mylicie sie, da sie - wystarczy uzyc 2 classloaderow, poniewaz w 2 classloaderach mozna miec te same klasy w roznych wersjach. Tyle ze, jnie jest to latwe, na pewno wygeneruje mase bledow typu ClassCastException(cannot cast ABC to ABC) -> i badz tu madry co sie dzieje) itp. Te 2 classloadery to np. URLClassLodery skofigurowane tak, aby jeden ladowal jednego jara, a drugi drugiego. Ale, wtedy aplikacja musi zonglowac classloaderami, uzywac odpowiedniego, jesli sa watki to zabawy z setContextClassLoader itp itd - ogolnie nie polecam.
Takie rzeczy robi tez OSGi - tam robisz bundle, ktore w manifescie mowia od czego zaleza, i juz kontener OSGi sobie sam tworzy classloadery i laduje wersje ktore sa wymagane przez bundla. Czyli, robisz 2 bundle, jeden zalezy od 1 wersji, drugi od 2, i OSGi sobie poradzi. Przy czym tez masa problemow, OSGi to ciezka krowa, aplikacje pisze sie inaczej niz normalnie...
Java 8 miala miec Jigsaw, czyli wlasnie standardowa modularyzacje dla Javy, ale w ostatnim miesiacu sie okazalo, ze raczej nie bedzie tego miec, bo nie zdarza do przyszlego roku. Osobiscie jestem bardzo rozczarowany.
Jest to termin znany pod pojeciem 'dll hell' lub dla javy 'jar hell' - 2 biblioteki maja zaleznosci od tej samej, 3. biblioteki, ale w roznych wersjach, i nie dzialaja z innymi.
Podstawowe pytanie do ojca prowadzacego - po kiego grzyba chcesz sam sobie strzelac w kolano i uzywac 2 wersje tego samego?