Java Classloader - jak odwoływać się do różnych wersji słoiczka

Question

Jest to typowy problem. Używam 2 bibliotek, które zależą od różnych wersji tego samego słoika.
Powiedzmy, że w czasie wykonywania muszę THIS.xxxjar

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

mogę skompilować specyficzną słoik (A.jar/B.jar) przed jego uzależnienia, ale przy starcie mam załadować tylko 1 wersja. Który?
Zależność tylko od obciążenia 1 (najnowsza wersja) oznacza, że ​​mój kod prawdopodobnie wyrzuci wyjątki w czasie wykonywania, jeśli biblioteki nie są kompatybilne z poprzednimi wersjami (czy są tam biblioteki zgodne z poprzednimi wersjami?).

W każdym razie wiem, że coś takiego jak OSGi może rozwiązać ten problem.
Zastanawiam się co to stary sposób na rozwiązanie tego rodzaju problemów ...

Thanks a lot

Answer 1

"Stara droga", o której wspomniałeś (i której OSGI z pewnością używa pod maską), to zainstaluj własną klasę ClassLoader dla obu gałęzi twoich zależności. W ten sposób na przykład serwery aplikacji mogą uruchamiać starsze i nowsze wersje tej samej aplikacji w tej samej maszynie JVM.

Przeczytaj o hierarchii modułów ładujących.

W twojej konfiguracji trudną częścią jest punkt wspólny, w którym spotykają się klasy z obu oddziałów. Żadne gałęzie nie mogą używać klas załadowanych do innego. Aby to zadziałało, upewnij się, że tylko klasy załadowane przez bootloader klasy (klasy JRE) lub classloader z pliku MY.jar są przekazywane do obu gałęzi.

Answer 2

wiele bibliotek są wstecznie kompatybilne. Ale nie wszystkie ..

---

Stary sposób polega na próbie uzależnienia od tylko jednej wersji.

Prawdopodobnie bezpieczniej jest skompilować obie wersje z tą samą wersją (najnowszą).
Przynajmniej otrzymujesz błędy podczas kompilacji, zamiast błędów w czasie wykonywania.

W razie potrzeby można zmienić trochę swoją bibliotekę, która działa ze starą zależność ...
będzie to wymagało dostępu do źródła ...

---

Należy pamiętać, że zgodność w czasie kompilacji nie gwarantuje poprawnego działania środowiska wykonawczego. Jest to jeden krok, potem można:

• odczytać pliku whatsnew dla nowej wersji słoika
• spojrzenie na Internet dla zgłaszających problemy z kompatybilnością
• zapisu JUnits
• użytkowników porównać kody oba słoiki:

Answer 3

OSGi może naprawić ten problem. Pakiet OSGi to nic innego jak słoik z dodatkowymi wersjami szczegółów metadanych. Pakiet ma numer wersji i będzie zawierać szczegółowe numery wersji (lub zakresy) zależnych słoików.

Aby uzyskać więcej informacji, zobacz this introductory Javaworld article.

Aby rozwiązać ten problem bez OSGi, należy ręcznie skompilować i uruchomić z kompatybilnymi jarami. Jak odkryłeś, niekoniecznie jest to banalne zadanie. Ponieważ słoiki niekoniecznie identyfikują ich wersje, jedyny pewny sposób to zrobić, aby nagrać/porównać sumy kontrolne lub podpisy.

Answer 4

Jak wspomniano w KLE, domyślnym podejściem jest uzależnienie od nowszej wersji. Nie ma żadnej gwarancji, ale przez większość czasu to działa. Prawdopodobnie najlepszym sposobem (będąc bycie rozdętym) jest używanie OSGI do przebrnięcia przez to.

Answer 5

Aby przekazać podstawowe „oldway” Wdrożenie kasę https://github.com/atulsm/ElasticsearchClassLoader

Stanowi to podejście do obsługi zakaz wstecz kompatybilne wersje elasticsearch użytkowania klienta.