[Java] Dynamiczne dołączanie bibliotek

Witam,

chciałem wprowadzić do swojego programu modularyzację i mam problem. Moja wizja jest następująca:
Mam w katalogu głownym plik wykonywalny JAR mojego programu oraz plik config.txt, w którym będę dopisywał polecenia ładowania poszczególnych modułów. W jakimś podkatalogu będą biblioteki java (moduły). I teraz przy starcie program czyta polecenia z pliku config.txt i odpowiednio ładuje moduły (tworzy instancje klas znajdujących się w bibliotekach). Chodzi mi o to żebym mógł sobie wstawiać nowe biblioteki bez ponownego kompilowania całego programu. Ktoś ma pomysł jak stworzyć obiekt klasy znajdującej się w osobnym JAR'e?

Na moje to Twoje rozwiazanie wyglada na to samo co robi classpath.

Nie mam w tym doświadczenia, ale poszedł bym w tym kierunku:

• ten folder z bibliotekami musi być podany jako classpath
• później ładujesz dowolną bibliotekę przez:
  http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Class.html#forName%28java.lang.String%29

Jeśli dobrze rozumiem to, co zamierzasz, mk761203 dobrze mówi...
Musisz je dodać do classpath programu przed odpaleniem, ale żeby użyć tego, co jest w tych bibliotekach, albo musiałbyś rekompilować, albo odpalać to przez reflection api ...

A popatrz sobie na coś co nazywa się OSGi. Łatwiej, prościej i większe możliwości.

OSGI jest "prostsze i latwiejsze" niz podanie jarow w classpath? Wolne zarty. A jak pozniej wywolasz klasy z takiego jara? Rowniez kompilujesz z interfejsami a pozniej refleksja. OSGI to nie zadne czary, a tutaj ich nie potrzeba, z tego co widac gosciu chce zduplikowac classpath.

@::., przeczytaj o co dokładnie chodzi. Zadanie polega na dynamicznym doładowaniu modułów już po wystartowaniu programu. Inaczej mówiąc w pierwszym kroku na podstawie pliku config.txt wczytujemy listę jarów. Metoda kiepska. Dynamiczne ładowanie jarów ma dużo wad w dodatku można zrobić to bardziej elegancko. Na pierwszy ogień budowanie classpath i Class.forName. Nie za dobrze, bo trzeba znać nazwy głównych klas modułów. Czyli znowu jakiś plik konfiguracyjny.
Druga metoda użycie Services > Własne usługi w JSE fajnie. Działa, można wrzucić sobie jary w jedno miejsce i ładować przy starcie. Nadal jednak brakuje elementu dynamicznego pozwalającego na doładowanie jara bez restartu. Odpalamy zatem OSGi i mamy pełną funkcjonalność o jaka nam chodzi. Fakt na początku trzeba zmienić sposób myślenia o ładowaniu aplikacji oraz można się zamotać z konfiguracją bundli, ale później jest już znacznie łatwiej.

@Koziołek - chcesz ruszać takiego potwora jak OSGi tylko po to aby ominąć jednego pliku konfiguracyjnego ?

to chyba trochę jak byś chciał do narysowania koła w aplikacji Swingowej wykorzystać osadzony element JavaFX

albo Swinga do zrobienia IoC na 3 obiektach

:P

@walec 51, w tym przypadku będzie to raczej mała operacja, którą można przeprowadzić z tutorialem w ręku.

Przeczytalem pierwszy post i w drugim zapytalem o co chodzi. Moim zdaniem to jest zwyczajne dzialanie classpath, nie zaprzeczyl wiec zakladam ze tak jest. Zapinanie OSGi do takiego czegos jest moim zdaniem po prostu smieszne. Ale Koziolek juz tak ma: wiara pyta o ladowanie jarow, mowi: OSGi; pytasz o laczenie z JDBC, mowi: JPA.

Czy dobrze rozumiem? Refleksja wymaga aby archiwum znajdowało się w katalogu głównym JAR'a wykonywalnego (lub głębiej, ale w JAR'ze), a my chcąc ominąć to ograniczenie robimy wpis w CLASSPATH tak?

Nie. Jesli masz jary w classpath w czasie kompilacji, to uzywasz klas w kodzie i nie musisz miec refleksji. Jesli nie znasz jarow i dolaczone sa dopiero w czasie runtime, to kompilujesz z interfejsami, a prawdziwe implementacje musisz jakos moc skonfigurowac. Np spring - podajesz klasy w xml (tak wiem ze sa adnotacje ale ten przyklad lepiej pasuje). No i wtedy musisz uzywac refleksji zeby utworzyc obiekt, przypisujesz go do referencji na interfejs i wolasz metody interfejsu.

::. napisał(a)

Ale Koziolek juz tak ma: wiara pyta o ladowanie jarow, mowi: OSGi; pytasz o laczenie z JDBC, mowi: JPA.

Niektórzy po prostu kochają złożoność :P

Użyć Spring'a do robienia IoC na 3 obiektach też jest ładnie, prosto i po prostu głupio, bo ładujesz do projektu 3 MB jar'ów i spory niepotrzebycode base, w których mogą czaić się rozmaite bugi.

Tu tak samo 0,5 MB jarów i spory standard do załatwienia pierdoły.

@walec51, nie komplikuję tylko z doświadczenia wiem, że z tych trzech klas już jutro zrobi się 5, a po jutrze 25. Dodatkowo przygotowałem sobie kiedyś całkiem zgrabne repozytorium archetypów do mavena i w praktyce odpada mi każdorazowe użeranie się z konfiguracją takiego springa czy hibernate.

No czyli tu jest podejscie: Spring jest do wszystkiego, kazdej aplikacji, bo przeciez moze sie rozrosnac.

@::., doczepiłeś się Springa. Poza tym uznaję EJB 3+ oraz Google Guice. Ten ostatni jest nawet fajny do małych projektów.

Nie mam nic do Springa. Guice bardzo lubie, fajnie ze Ty rowniez. Jestem przeciwny odpowiadaniem na pytania newbies w Twoim stylu. Jak npiasalem - nie kazdy kto pyta o JDBC chce jako odpowiedzi dostac "uzywaj JPA", a w tym watku z OSGi to juz w ogole pojechales po bandzie.
No ale dobrze. Kazdy projekt wymaga JPA, kazdy projekt wymaga DI, kazdy projekt bedzie sie rozrastal a wiec bedzie mial nowe moduly i wymaga OSGi. Od poczatku.

Koziołek napisał(a)

@walec51, nie komplikuję tylko z doświadczenia wiem, że z tych trzech klas już jutro zrobi się 5, a po jutrze 25. Dodatkowo przygotowałem sobie kiedyś całkiem zgrabne repozytorium archetypów do mavena i w praktyce odpada mi każdorazowe użeranie się z konfiguracją takiego springa czy hibernate.

Z mojego doświadczenia wynika że 90% projektów zostaje zaniechanych lub zamrożonych przed osiągnięciem jakiegoś większego stopnia złożoności.

poza tym tak jak już mówiłem. To że ci to łatwo wszczepić w projekt o niczym nie świadczy. Generalnie im mniej zbędnych w danym kontekście technologi i zależności tym lepiej.

PS. Czysty Spring to dla mnie też zależność. Co z tego nie wykorzystujesz jego API skoro te xml'e robią się bardziej złożone niż nie jedna klasa w systemie.