Hej,
mam pytanie jak mogę użyć 2 wersji tego samego jara (starsza i nowsza) w jednym projekcie.
Pisze mała aplikacje jsp w eclipse i potrzebuje obu bibliotek żeby połaczyc sie ze stara i nowa wersja systemu.
Być może jest jakiś sposób aby jeden pakiet korzystał ze starej wersji JAR a drugi pakiet z nowej?
Dziekuje za odpowiedzi!
Nie da sie tak zrobić, bo java nie ma obsługi wersji bibliotek. W trakcie uruchamiania programu wszystkie klasy ląduja w tym samym worku.
musi byc jakis workaround :)
np stworzyc drugi projekt i podlinkowac go? probowalem tak ale czegos mi tam tez brakuje
ale to w jednej aplikacj, ze tak powiem w jednym uruchomieniu musisz sie podpinac do nowej i starej wersji?
Jesli nie i korzystasz z mavena, to mozna tak poustawiac profile i biblioteki, żeby ładował odpowiednie.
@lonas jeśli potrzebujesz uruchomić jeden program javowy, który będzie miał w sobie dwie wersje tej samej klasy, to się tak po prostu nie da, bo Java nie ma czegoś takiego jak "wersje klas".
Jak się ktoś bardzo uprze ...
URL urls = new URL[1];
urls[0] = new File(nazwaJara).toURI.toURL();
ClassLoader loader = new URLClassLoader(urls);
Class<?> klasa = loader.load(nazwaKlasy);
ob = klasa.newInstance();
Pisałem z pamięci i zrobiłem trochę błędów (musi być URLClassLoader, argumentem jest tablica adresów).
tak w jednym uruchomieniu mam 2 okna formatki do logowania i chce jednoczesnie zalogowac sie do starego i nowego systemu - uzywajac starej i nowej biblioteki.
problem wlasnie w tym ze nazwy klas i jarów sa takie same - potrzebowałbym to rozdzielic w aplikacji
Dostałeś przykład kodu jak czytać klasy ze wskazanego jara.
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?
Mozesz zrobic taki myk, ktory czesto robia biblioteki uzywajace asm lub cglib (groovy, mockito, google guice, spring, wiele innych) do manipulacji bytecodu - zrepakowac jedna wersje tak, aby np. pakiety mialy jakis prefix, np. nowa wersja zostaje taka sama, i klasa sie nazywa org.costam.Klasa, a stara wersja ma nazwe old.org.costam.Klasa. Poszukaj w necie jak to mozna zrobic, na pewno sa pluginy do mavena ktore w czasu builda dokonaja takich transformacji.
Ponieważ mam 2 wersje systemu (stara i nowa) , działające równolegle (migracja)
Stara wersja używa starych JARow nowa nowych. Potrzebuje sie zalogowac do obu aplikacji i porównać zawartosc repozytorium.
Zmiana nazwy pakietów nie jest najlepszym rozwiązaniem jeżeli komunikacja pomiędzy aplikacją klienta, a serwerem wykorzystuje np. obiekty transportowe. W tym momencie trzeba też podmienić nazwy na serwerze, bo inaczej nie ruszą wywołania zdalne (niezgodna nazwa klasy/metody). Jest trochę prostszy sposób, ale wymaga trochę pracy.
Co jest złego w ładowaniu jarów osobnymi classloaderami? Jakoś nie widzę problemu i raczej jest to najprostsze rozwiązanie. Serwery aplikacyjne / webowe i inne frameworki robią tak od lat, właśnie dlatego aby ich biblioteki nie kolidowały z bibliotekami, które chce dołączyć użytkownik.
@Krolik: Ty moze tak umiesz robic, ja tez, ale pisanie aplikacji z classloaderami to dla wiekszosci nie jest bulka z maslem, wiekszosc devow tutaj nie wie pewnie co to classloader. Sadzac po pytaniu w tym watku, autor rowniez nie ma wielkiego doswiadczenia i moze miec duzo problemow.
Dlatego bym zrobił tak, że część z classloaderami wydzieliłbym tylko do jednego pakietu, który wystawia API dla reszty aplikacji w pełni kompatybilne z głównym classloaderem. Co oznaczałoby, że w wyłoaniach metod, jak również w zwracanych wynikach nie wolno byłoby korzystać z inastancji załadowanych tymi specjalnymi classloaderami do problematycznej biblioteki. Korzystanie ze złożonych rozwiązań nie jest złe, jeśli da się całą komplikację zamknąć w jednym dobrze zdefiniowanym miejscu. Przy okazji zaleta tego jest taka, że nikogo nie będzie korciło aby instancje klas tej specyficznej biblioteki do czegośtam latały bez kontroli po całym projekcie.