OSGi, modułowość Java i Jigsaw


95

Więc od wczorajszego ranka nie miałem pojęcia, czym w ogóle był OSGi. OSGi było tylko modnym hasłem, które ciągle pojawiało się w kółko, więc w końcu poświęciłem trochę czasu, aby to odświeżyć.

Właściwie wydaje się to całkiem fajne, więc chciałbym zacząć od stwierdzenia (dla porządku), że pod żadnym względem nie jestem przeciwny OSGi, ani nie jest to jakieś pytanie o "walenie w OSGi".

Ostatecznie wydaje się, że OSGi - w zasadzie - zajęło się JSR 277 w Java Modularity, które uznało, że istnieją niedociągnięcia w JARspecyfikacji pliku, które mogą prowadzić do rozwiązywania przestrzeni nazw i problemów z ładowaniem klas w niektórych przypadkach narożnych. OSGi robi również wiele innych naprawdę fajnych rzeczy, ale z tego, co mogę stwierdzić, to jego największa atrakcja (lub jedna z nich).

Dla mnie - jako całkiem nowego (od kilku lat) programisty Java EE, jest absolutnie zadziwiające, że jesteśmy w roku 2011 i obecnie żyjemy w erze Java 7 i że te problemy z ładowaniem klas są nadal obecne; szczególnie w środowiskach korporacyjnych, gdzie jeden serwer aplikacji może mieć setki plików JAR, przy czym wiele z nich zależy od różnych wersji i wszystkie działają (mniej więcej) jednocześnie.

Moje pytanie:

Tak jak jestem zainteresowany OSGi i chociaż chcę zacząć się o nim uczyć, aby zobaczyć, gdzie / czy może być przydatny w moich projektach, po prostu nie mam czasu, aby usiąść i nauczyć się czegoś tak dużego, przynajmniej teraz.

Co więc mają zrobić programiści spoza OSGi, gdy pojawią się te problemy? Jakie rozwiązania Java (Oracle / Sun / JCP) są obecnie dostępne? Dlaczego wyrzynarka została wycięta z J7? Na ile pewna jest społeczność, że Jigsaw zostanie wdrożony w przyszłym roku w J8? Czy można uzyskać Jigsaw do swojego projektu, mimo że nie jest on jeszcze częścią platformy Java?

Myślę, że to o co tutaj pytam to połączenie paniki, intrygi i facepalm. Teraz, kiedy w końcu rozumiem, czym jest OSGi, po prostu nie rozumiem, jak coś takiego jak Jigsaw zajęło ponad 20 lat, zanim doszło do skutku, a potem jak można to było powstrzymać po premierze. Wydaje się to po prostu fundamentalne.

Jako programista jestem również ciekawy, jakie są moje rozwiązania bez OSGi.

Również Uwaga : Wiem, że to nie jest „ programowanie czysty ” -type pytanie, ale zanim niektórzy z was wasze nosy odkształcone, chciałem stanu (ponownie, do dokumentacji), że celowo umieścić na to pytanie WIĘC. To dlatego, że mam tylko najwyższy szacunek dla moich kolegów SO-ów i szukam odpowiedzi na poziomie architektonicznym od niektórych „bogów IT”, których czają się tu każdego dnia.

Ale dla tych z Was, którzy absolutnie nalegają, aby pytanie SO było poparte jakimś segmentem kodu:

int x = 9;

(Dziękuję każdemu, kto może się zastanowić nad tym OSGi / Jigsaw / classloader / namespace / JAR piekło!)


Cóż, Java 9 jest dostępna od wczoraj, z Jigsaw. Miło czytać:
Obalono

Odpowiedzi:


100

Najpierw zrozum, że podstawowym przypadkiem użycia Jigsaw jest modularyzacja samego środowiska JRE. Drugorzędnym celem będzie oferowanie systemu modułowego, który może być używany przez inne biblioteki i aplikacje Java.

Moje stanowisko jest takie, że coś takiego jak Jigsaw jest prawdopodobnie potrzebne tylko dla środowiska JRE, ale spowoduje znacznie więcej problemów, niż twierdzi, że je rozwiązuje, jeśli jest używane przez inne biblioteki lub aplikacje Java.

Środowisko JRE to bardzo trudny i szczególny przypadek. Ma ponad 12 lat i jest przerażającym bałaganem, podziurawionym cyklami zależności i bezsensownymi zależnościami. Jednocześnie jest używany przez około 9 milionów programistów i prawdopodobnie miliardy działających systemów. Dlatego absolutnie nie można refaktoryzować środowiska JRE, jeśli taka refaktoryzacja powoduje istotne zmiany.

OSGi to system modułowy, który pomaga (a nawet zmusza do) tworzenia oprogramowania, które jest modułowe. Nie można po prostu dodać modułowości do istniejącej niemodularnej bazy kodu. Przekształcenie niemodularnej bazy kodu w modularną nieuchronnie wymaga pewnych refaktoryzacji: przeniesienia klas do odpowiedniego pakietu, zastąpienia bezpośredniego tworzenia instancji usługami odsprzęgniętymi i tak dalej.

To sprawia, że ​​trudno jest zastosować OSGi bezpośrednio w bazie kodu JRE, ale nadal istnieje wymóg podzielenia środowiska JRE na oddzielne części lub „moduły”, aby można było dostarczyć okrojone wersje JRE.

Dlatego uważam Jigsawa za rodzaj „ ekstremalnego środka ”, który ma utrzymać kod JRE przy życiu podczas dzielenia go. Czyni nie kod pomocy, aby stać się bardziej modularny, a jestem przekonany, że będzie to rzeczywiście zwiększyć utrzymanie wymaganej ewoluować żadnej biblioteki lub aplikację, która go używa.

Wreszcie: OSGi istnieje, podczas gdy Jigsaw jeszcze nie istnieje i może nigdy nie istnieć. Społeczność OSGi ma 12 lat doświadczenia w tworzeniu aplikacji modułowych. Jeśli jesteś poważnie zainteresowany tworzeniem aplikacji modułowych, OSGi jest jedyną grą w mieście.


Czy to ty też? slideshare.net/mfrancis/ ... prawie taka sama zawartość.
Jin Kwon

Istnieją również moduły JBoss: docs.jboss.org/author/display/MODULES/Introduction Jest również używany przez Cejlon (ceylonlang.org). Zobacz ten wątek na forum użytkowników Cejlonu: groups.google.com/forum/?hl=de#!topic/ceylon-users/RmDskLDNkug
OlliP

Czy końcowe stwierdzenie: „Jeśli poważnie interesujesz się tworzeniem aplikacji modułowych, OSGi jest jedyną grą w mieście” nadal jest aktualne?
Adam Arold

1
@AdamArold Myślę, że tak. Jigsaw nadal nie istnieje w żadnej wydanej wersji Java. JSR 376 (Java Platform Module System) wciąż tworzy swoją grupę ekspercką i nie rozpoczął jeszcze nawet pierwszej wersji roboczej. Java 9 ma być dostępna dopiero za rok, a nawet po wydaniu nie ma gwarancji, że będzie miała modułowość (wymknęła się z Java 7, a następnie z Java 8 i może łatwo się ześlizgnąć). Wreszcie, opublikowane wymagania dla JSR376 stwierdzają, że wymagana jest współpraca OSGi ... więc przyjęcie OSGi pozostaje bezpiecznym wyborem, a dziś jedynym praktycznym wyborem.
Neil Bartlett

2
@AdamArold OK, to trochę inne pytanie! Można powiedzieć, że OSGi to architektura mikrousług, ale wiem, co mówisz. Dla mnie pomysł modelowania każdej usługi jako procesu jest znacznie bardziej złożonym problemem, jeśli chodzi o zarządzanie, bezpieczeństwo i narzut komunikacyjny. OSGi jest prostsze i szybsze. To powiedziawszy, bardzo łatwo jest używać usług zdalnych OSGi do przenoszenia usług do iz bariery procesu, więc uważam, że jest to dobry wybór dla technologii wdrażania mikrousług.
Neil Bartlett

21

To proste, jeśli chcesz dziś tworzyć prawdziwe komponenty w Javie, to OSGi jest jedyną grą w mieście.

Moim zdaniem Jigsaw to połączenie kompromisu tego, co jest do zrobienia w JDK i wcześniejszych złych relacji między SUNem a gośćmi z OSGi. Może będzie dostarczany z Javą 8, ale musimy poczekać i zobaczyć.

OSGi nie jest panaceum, jeśli pracujesz w typowym środowisku korporacyjnym i będziesz musiał zapoznać się z działaniem ładowania klas, ponieważ wiele dobrze znanych bibliotek (patrząc na ciebie, Hibernate) przyjęło założenia dotyczące widoczności klas, które są już nieaktualne wewnątrz OSGi.

Lubię OSGi, ale nie próbowałbym go modernizować do istniejącego systemu. Rozważyłbym również zalety i wady w kontekście rozwoju greenfield - poleciłbym przyjrzeć się produktom Apache lub Eclipse, które upraszczają życie OSGi, a nie robić tego samemu.

Jeśli nie robisz OSGi, to masz pecha, jeśli wymyśliłeś system, który ma zależności od różnych wersji tej samej biblioteki - wszystko, co możesz zrobić, to spróbować uniknąć problemu, chociaż potrzebujesz wielu wersji Biblioteka wydaje mi się „zapachem” architektury.


Tak, pomyślałem, że między Sunem a Sojuszem OSGi było dużo „złej krwi”. Nie wyobrażam sobie jednak, że Oracle pozwoli, by sprawy wymknęły się spod ich kontroli. Naprawdę mówisz mi, że nie ma planów, aby naprawdę naprawić (nie zhakować) te piekło JAR w najbliższym czasie? To oszałamia!
IAmYourFaja

6
@Mara To niesprawiedliwe powiedzieć, że jest zła krew. W końcu Sun był jednym ze współtwórców OSGi około 12 lat temu (JSR 8). Sun ponownie dołączył do OSGi Alliance jako pełnoprawny członek, około rok przed przejęciem Oracle. Stworzyli też sporo oprogramowania na bazie OSGi, sprzed Oracle. Najbardziej oczywistym przykładem jest Glassfish. Jednak można uczciwie powiedzieć, że istnieją tarcia między niektórymi osobami w Sun / Oracle i OSGi.
Neil Bartlett,

15

Uwielbiam, gdy do opisania obecnej sytuacji używasz wyrażenia „przypadki narożne”.

istnieją niedociągnięcia w specyfikacji pliku JAR, które mogą prowadzić do rozwiązywania przestrzeni nazw i problemów z ładowaniem klas w niektórych przypadkach narożnych

W każdym razie od wielu lat interesują mnie narzędzia i techniki, które wspierają tworzenie, a nawet lepiej egzekwują kod, który jest czystszy, bardziej odsprzężony, spójniejszy i łatwiejszy w utrzymaniu niż to, co prawdopodobnie byłoby wynikiem bez nich. Test Driven Design i Junit to takie połączenie.

Po kilku miesiącach przenoszenia znacznej części naszego kodu do OSGi, powiedziałbym, że OSGi jest jeszcze lepszym narzędziem pod tym względem. I to jest naprawdę wystarczający powód, aby przejść do OSGi. Na dłuższą metę pozwoli Ci to zaoszczędzić sporo pieniędzy.

A jako bonus da ci szansę zrobienia wielu fajnych rzeczy. Wyobraź sobie, że podczas demonstracji bezproblemowo uaktualniasz moduł uwierzytelniania, bez utraty ruchu, do obsługi OAuth ... nagle znowu tworzy się radość!

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.