Dlaczego pakiety i moduły są odrębnymi koncepcjami w Javie 9?

Java 9 będzie zawierać moduły oprócz pakietów. Zwykle języki mają jeden lub drugi. I większość programistów postrzega dwa terminy jako synonimy. Moduły są zbudowane na pakietach, traktując je jak prymitywy. Wzór złożony sugeruje równomierne traktowanie prymitywów i kompozytów. W przeciwnym razie zdarzają się złe rzeczy. Na przykład spójrz na projekt Valhalla, w którym starają się zmodernizować wspólny nadtyp dla typów pierwotnych (wartość) i referencyjnych.

Czy moduły i pakiety reprezentują semantycznie odrębne pojęcia? Oznacza to, że rozsądnie jest mieć oba w dowolnym języku (oddzielenie problemów). Czy Java musi mieć jedno i drugie jako hołd dla wstecznej kompatybilności?

Po co wprowadzać nową koncepcję zamiast rozszerzać istniejącą?

JSR 376 : „System modułów platformy Java” zaimplementowany w ramach projektu Jigsaw .

Według SOTMS

Moduł to nazwany, samoopisujący zbiór kodu i danych. Jego kod jest zorganizowany jako zestaw pakietów zawierających typy, tj. Klasy Java i interfejsy; jego dane obejmują zasoby i inne rodzaje informacji statycznych.

JLS ostrożnie unika definiowania pakietu . Z Wikipedii :

Pakiet Java to technika porządkowania klas Java w przestrzeniach nazw podobnych do modułów Modula, zapewniająca programowanie modułowe w Javie.

Wiem, że cytowanie Wikipedii jest złą praktyką, ale odzwierciedla powszechne zrozumienie. Od pozycji programowania modułowego:

Termin pakiet jest czasem używany zamiast modułu (jak w Dart, Go lub Java). W innych implementacjach jest to odrębna koncepcja; w Pythonie pakiet jest kolekcją modułów, podczas gdy w nadchodzącej Javie 9 planowane jest wprowadzenie nowej koncepcji modułów (zbiór pakietów z rozszerzoną kontrolą dostępu).

Pojęcie modułu różni się od konkretyzacji tego pojęcia.

Java zawsze miała moduły. Metoda jest modułem, podobnie jak klasa, podobnie jak pakiet. Moduł to jednostka organizacyjna, w której wewnętrzne szczegóły są ukryte i która komunikuje się z innymi modułami za pośrednictwem uzgodnionych umów. Na przykład metoda jest modułem, ponieważ ma ukryte elementy wewnętrzne (kod i zmienne lokalne) oraz kontrakt (parametry i typ zwracany). Moduły można składać z modułów niższego poziomu, np. Klasy zawierają metody.

W rdzeniu Java (wcześniejszym niż 9) brakuje modułu, który można wdrożyć . Wszystkie powyższe rodzaje modułów nie są jednostkami do rozmieszczenia, które można kopiować. Java ma artefakt, który można wdrożyć, zwany plikiem JAR, ale nie są to moduły, ponieważ nie mają enkapsulacji ani kontraktu: w czasie wykonywania pliki JAR znikają, wszystkie łączą się w jedną „ścieżkę klas”.

OSGi zajęło się brakiem modułów możliwych do wdrożenia w 1998 r. Dzięki koncepcji „pakietu”. Są to fizycznie pliki JAR i zawierają pakiety, ale OSGi definiuje dodatkowe metadane wraz z systemem wykonawczym do obsługi enkapsulacji i kontraktów na tym poziomie.

Java 9 rozwiązuje problem braku modułów do wdrożenia w podobny sposób jak OSGi. Prawdopodobnie było to zupełnie niepotrzebne, ponieważ OSGi istnieje i działa, ale to zupełnie inna dyskusja ...

Niestety Java 9 zamazuje wody, nazywając nową koncepcję modułu tylko „modułem”. Nie oznacza to, że metody, klasy i pakiety przestają być modułami! „Moduł” J9 to kolejna instancja koncepcji modułu . Podobnie jak pakiety OSGi, moduły J9 są zbudowane z pakietów i są fizycznymi artefaktami (zwykle ponownie plikami JAR), które można kopiować. System wykonawczy je rozumie i weryfikuje.

Podsumowanie: tak Moduły i pakiety J9 są semantycznie oddzielnymi pojęciami. Oczywiście Java musi zachować istniejącą koncepcję pakietu w celu zapewnienia kompatybilności wstecznej. Zauważ, że słowo „pakiet” jest używane zupełnie inaczej w Javie niż w innych językach lub w systemach zarządzania pakietami, takich jak RPM. Nowe moduły J9 (i pakiety OSGi) są znacznie bardziej podobne do pakietów w RPM niż kiedykolwiek były pakiety Java.

Pozwól, że zaryzykuję odpowiedź, choć większość z nich może być założeniami / rozdwajaniem włosów / rantowaniem itp.

Czy to to samo? Cóż, tak ^_i nie

Z tego artykułu JavaWorld na temat „Modułowości w Javie 9” :

Pakiety jako rozwiązanie modułowe

Pakiety próbują dodać poziom abstrakcji do środowiska programowania Java. Zapewniają udogodnienia dla unikatowych przestrzeni nazw kodowania i kontekstów konfiguracji. Niestety, konwencje pakietów można łatwo obejść, co często prowadzi do powstania środowiska niebezpiecznych połączeń podczas kompilacji.

Jak wskazał @ user2418306 (OP) , „ moduły to pakiety wykonane poprawnie ” . Moduły i pakiety w Javie (oczywiście od Java 9) są (jak pyta OP) semantycznie to samo. Oznacza to, że są to zbiory prekompilowanego kodu bajtowego JVM z innymi metadanymi - w zasadzie są bibliotekami .

Jaka jest różnica?

Różnica polega jednak na metadanych wewnątrz każdego z nich. packageManifesty Java lub manifesty JAR często nie są obsługiwane przez programistów bibliotek, ani nie zawierają żadnej pewnej umowy dotyczącej tego, co zapewnia pakiet JAR / pakiet. Jak wyjaśniono tutaj (ponownie artykuł JavaWorld) :

Czy pliki JAR nie są wystarczająco modułowe?

Pliki JAR i środowisko wdrażania, w którym działają, znacznie poprawiają wiele starszych konwencji wdrażania dostępnych w innym przypadku. Ale pliki JAR nie mają żadnej wewnętrznej wyjątkowości, oprócz rzadko używanego numeru wersji, który jest ukryty w pliku .jar. Plik JAR i opcjonalny manifest nie są używane jako konwencje modułowości w środowisku wykonawczym Java. Zatem nazwy pakietów klas w pliku i ich udział w ścieżce klas są jedynymi częściami struktury JAR, które nadają modułowość środowisku wykonawczemu.

Rant na temat innych języków / środowisk itp

Innym obszarem omówionym w tym artykule są systemy takie jak Maven , które zarządzają zależnościami w ramach procesu kompilacji. Z tej strony w witrynie Apache Maven :

Zarządzanie zależnościami:

Maven zachęca do korzystania z centralnego repozytorium plików JAR i innych zależności. Maven jest wyposażony w mechanizm, za pomocą którego klienci twojego projektu mogą pobierać dowolne pliki JAR potrzebne do zbudowania projektu z centralnego repozytorium JAR, podobnie jak CPAN Perla. Pozwala to użytkownikom Maven na ponowne użycie plików JAR w różnych projektach i zachęca do komunikacji między projektami, aby zapewnić rozwiązanie problemów z kompatybilnością wsteczną.

Teraz mówię o przyszłości, jakbym tam był

Jak wspomniano na tej stronie , inne języki (takie jak Perl) mają repozytoria pakietów (jak CPAN ). Jest to rosnąca tendencja (mówię, ponieważ mam na to ochotę, bez wyraźnego dowodu), w ciągu ostatniej dekady. Narzędzia, takie jak klejnoty Ruby , PyPi Pythona i menedżer pakietów Node ( npm) , bazują na tym, aby zapewnić spójny sposób konfigurowania środowiska (programistycznego, kompilacyjnego, testowego lub uruchomieniowego itp.) Za pomocą odpowiednich elementów (pakietów, modułów, klejnoty, gadżety itp.). Pomysł (wydaje mi się) został „ zapożyczony ” z systemów dystrybucyjnych Linux®, takich jak apt Debiana , RedHatarpmitp. (Chociaż oczywiście ewoluowało co najmniej jedno pokolenie i sprawiło, że wszystkie te rzeczy są ładniejsze.)

Moduły Java , chociaż niekoniecznie dodają nic, czego nie można już zrobić, znacznie ułatwiają oprzyrządowanie do zarządzania zależnościami / pakietami i zautomatyzowanymi kompilacjami . Nie wiem, czy to czyni moduły „lepszymi”. : P