System zarządzania pakietami w Javie zawsze wydawał mi się prosty i skuteczny. Jest intensywnie używany przez sam JDK. Używaliśmy go do naśladowania koncepcji przestrzeni nazw i modułów.
Co próbuje wypełnić Project Jigsaw (inaczej Java Platform Module System )?
Z oficjalnej strony:
Celem tego projektu jest zaprojektowanie i zaimplementowanie standardowego systemu modułowego dla platformy Java SE oraz zastosowanie tego systemu na samej platformie oraz w JDK.
Odpowiedzi:
Jigsaw i OSGi próbują rozwiązać ten sam problem: jak pozwolić gruboziarnistym modułom na interakcję, jednocześnie chroniąc ich elementy wewnętrzne.
W przypadku Jigsaw, bardziej zgrubne moduły obejmują klasy, pakiety i zależności Javy.
Oto przykład: Wiosna i hibernacja. Oba są zależne od zewnętrznego JAR CGLIB, ale używają różnych, niekompatybilnych wersji tego JAR. Co możesz zrobić, jeśli polegasz na standardowym JDK? Włączenie wersji, której chce Spring, przerywa Hibernate i vice versa.
Ale jeśli masz model wyższego poziomu, taki jak Jigsaw, możesz łatwo zarządzać różnymi wersjami JAR w różnych modułach. Pomyśl o nich jak o pakietach wyższego poziomu.
Jeśli zbudujesz Springa ze źródła GitHub , również to zobaczysz. Przeprojektowali framework, więc składa się z kilku modułów: core, persence, itd. Możesz wybrać i wybrać minimalny zestaw zależności modułów, których potrzebuje twoja aplikacja, a resztę zignorować. Kiedyś był to pojedynczy plik JAR Spring ze wszystkimi plikami .class.
Aktualizacja: pięć lat później - Jigsaw może nadal mieć pewne problemy do rozwiązania.
NoSuchMethodErrori NoClassDefFoundError.
AFAIK Planujemy uczynić środowisko JRE bardziej modułowym. To znaczy masz mniejsze słoiki, które są opcjonalne i / lub możesz pobrać / zaktualizować tylko te funkcje, których potrzebujesz.
Dzięki temu jest mniej rozdęty i daje możliwość upuszczenia starszych modułów, których być może większość ludzi nie używa.
importmetody, wszystko to robi, to wprowadzenie tej klasy do przestrzeni nazw klasy dla kompilatora. Jeśli faktycznie go nie używasz, nie pojawi się w utworzonym kodzie bajtowym. Jeśli faktycznie używasz tej klasy, musisz mieć tę klasę i każdą klasę, której używa w czasie wykonywania. Teoretycznie możesz stworzyć okrojoną wersję interfejsu API guawy, która będzie miała tylko to, czego potrzebujesz, i zamiast tego użyj tego pliku JAR. W rzeczywistości jest to podatne na błędy i niezbyt przydatne w większości przypadków, a kończy się na dodaniu całego pliku JAR w stanie, w jakim został wydany.
Na podstawie Mark Reinhold „s przemówienie na Devoxx Belgii , Projekt Jigsaw będzie dotyczą dwóch głównych punktów bólowych:
Wszyscy wiemy o piekle JAR . Termin ten opisuje wszystkie różne sposoby, w jakie proces ładowania klas może zakończyć się niepowodzeniem. Najbardziej znane ograniczenia ścieżki klas to:
Duży monolit JDK powoduje kilka problemów:
Aby rozwiązać powyższe problemy, traktujemy moduły jako fundamentalny nowy rodzaj komponentu programu Java. Moduł to nazwana, samoopisująca się kolekcja kodu i danych. Jego kod jest zorganizowany jako zbiór pakietów zawierających typy, tj. Klasy i interfejsy Java; jego dane obejmują zasoby i inne rodzaje informacji statycznych.
Aby kontrolować, w jaki sposób jego kod odwołuje się do typów w innych modułach, moduł deklaruje, jakich innych modułów wymaga do skompilowania i uruchomienia. Aby kontrolować, jak kod w innych modułach odwołuje się do typów w swoich pakietach, moduł deklaruje, które z tych pakietów eksportuje.
System modułów lokalizuje wymagane moduły i, w przeciwieństwie do mechanizmu ścieżki klas, zapewnia, że kod w module może odwoływać się tylko do typów w modułach, od których zależy. Mechanizmy kontroli dostępu języka Java i wirtualnej maszyny Java uniemożliwiają kodowi dostęp do typów w pakietach, które nie są eksportowane przez ich moduły definiujące.
Oprócz większej niezawodności modułowość może poprawić wydajność. Gdy kod w module odwołuje się do typu w pakiecie, wtedy pakiet ten jest zdefiniowany albo w tym module, albo dokładnie w jednym z modułów czytanych przez ten moduł. Szukając definicji konkretnego typu, nie ma zatem potrzeby wyszukiwania jej w wielu modułach lub co gorsza po całej ścieżce klasowej.
Jigsaw to ogromny projekt, który trwa już od kilku lat. Ma imponującą liczbę JEP-ów, które są świetnymi miejscami, w których można uzyskać więcej informacji o projekcie. Oto niektóre z tych JEP:
W pierwszej edycji raportu The State of the Module System Mark Reinhold opisuje następujące cele szczegółowe systemu modułowego:
Funkcje te przyniosą korzyści twórcom aplikacji, twórcom bibliotek i firmom wdrażającym samą platformę Java SE bezpośrednio, a także pośrednio, ponieważ zapewnią skalowalną platformę, większą integralność platformy i lepszą wydajność.
Dla celów argumentacji załóżmy, że Java 8 (i wcześniejsze) już je posiada „formę” modułów (jars) i systemu modułów (ścieżka klas). Ale są z nimi dobrze znane problemy.
Analizując problemy, możemy zilustrować motywację do Jigsaw. (Poniższy tekst zakłada, że nie używamy OSGi, modułów JBoss itp., Które z pewnością oferują rozwiązania.)
Problem 1: publiczny jest zbyt publiczny
Rozważ następujące klasy (załóżmy, że obie są publiczne):
com.acme.foo.db.api.UserDao
com.acme.foo.db.impl.UserDaoImpl
W Foo.com możemy zdecydować, że nasz zespół powinien użyć UserDao a nie używaćUserDaoImpl bezpośrednio. Jednak nie ma sposobu, aby wymusić to na ścieżce klas.
W Jigsaw moduł zawiera module-info.javaplik, który pozwala nam jawnie określić, co jest publiczne dla innych modułów. Oznacza to, że opinia publiczna ma niuanse. Na przykład:
// com.acme.foo.db.api.UserDao is accessible, but
// com.acme.foo.db.impl.UserDaoImpl is not
module com.acme.foo.db {
exports com.acme.foo.db.api;
}
Problem 2: refleksja jest nieokiełznana
Biorąc pod uwagę klasy w # 1, ktoś nadal mógłby to zrobić w Javie 8:
Class c = Class.forName("com.acme.foo.db.impl.UserDaoImpl");
Object obj = c.getConstructor().newInstance();
To znaczy: refleksja jest potężna i niezbędna, ale jeśli nie jest zaznaczona, może być wykorzystana do sięgnięcia do wnętrza modułu w niepożądany sposób. Mark Reinhold podaje dość niepokojący przykład . (Post SO jest tutaj .)
W Jigsaw silna enkapsulacja daje możliwość odmowy dostępu do klasy, w tym refleksji. (Może to zależeć od ustawień wiersza poleceń, w oczekiwaniu na poprawioną specyfikację techniczną JDK 9.) Należy zauważyć, że ponieważ Jigsaw jest używany w samym JDK, Oracle twierdzi, że pozwoli to zespołowi Java na szybsze unowocześnianie wewnętrznych elementów platformy.
Problem 3: ścieżka klas wymazuje zależności architektoniczne
Zespół zazwyczaj ma model mentalny dotyczący relacji między słoikami. Na przykład foo-app.jarmoże użyć, foo-services.jarktóre używa foo-db.jar. Moglibyśmy stwierdzić, że klasy w foo-app.jarnie powinny omijać „warstwy usług” i używać ich foo-db.jarbezpośrednio. Jednak nie ma sposobu, aby wymusić to za pomocą ścieżki klas. Mark Reinhold wspomina o tym tutaj .
Dla porównania Jigsaw oferuje wyraźny, niezawodny model dostępności dla modułów.
Problem 4: monolityczne środowisko wykonawcze
Środowisko wykonawcze Java jest monolityczne rt.jar. Na moim komputerze jest to ponad 60 MB z 20 000 klas! W dobie mikrousług, urządzeń IoT itp. Niepożądane jest posiadanie na dysku bibliotek Corba, Swing, XML i innych, jeśli nie są używane.
Jigsaw dzieli JDK na wiele modułów; np. java.sql zawiera znane klasy SQL. Ma to kilka zalet, ale nowe jest to jlinknarzędzie. Zakładając, że aplikacja jest całkowicie zmodularyzowana, jlinkgeneruje dystrybuowalny obraz czasu wykonywania, który jest przycinany tak, aby zawierał tylko określone moduły (i ich zależności). Patrząc w przyszłość, Oracle przewiduje przyszłość, w której moduły JDK będą kompilowane z wyprzedzeniem do kodu natywnego. Chociaż jlinkjest to opcjonalne, a kompilacja AOT jest eksperymentalna, są one głównymi wskazówkami, dokąd zmierza Oracle.
Problem 5: wersjonowanie
Jest dobrze wiadomo, że ścieżka klasy nie pozwala nam korzystać z wielu wersji tego samego słoika: Np bar-lib-1.1.jari bar-lib-2.2.jar.
Jigsaw nie rozwiązuje tego problemu; Mark Reinhold podaje tutaj uzasadnienie . Istota jest taka, że Maven, Gradle i inne narzędzia reprezentują duży ekosystem do zarządzania zależnościami, a inne rozwiązanie będzie bardziej szkodliwe niż korzystne.
Należy zauważyć, że inne rozwiązania (np. OSGi) rzeczywiście rozwiązują ten problem (i inne, oprócz punktu 4).
Podsumowanie
To kilka kluczowych punktów dla Jigsaw, motywowanych określonymi problemami.
Zwróć uwagę, że wyjaśnienie kontrowersji między Jigsaw, OSGi, JBoss Modules itp. To osobna dyskusja, która należy do innej witryny Stack Exchange. Różnic między rozwiązaniami jest znacznie więcej niż opisano tutaj. Co więcej, istniał wystarczający konsensus, aby zatwierdzić głosowanie w sprawie ponownego rozpatrzenia przeglądu publicznego dla JSR 376.
W tym artykule szczegółowo wyjaśniono problemy, które próbują rozwiązać zarówno OSGi, jak i JPMS / Jigsaw:
„Java 9, OSGi i przyszłość modułowości” [22 września 2016 r.]
Dokładnie omawia również podejście zarówno OSGi, jak i JPMS / Jigsaw. Jak na razie wydaje się, że autorzy nie wymienili prawie żadnych praktycznych zalet JPMS / Jigsaw w porównaniu z dojrzałymi (16-letnie) OSGi.