Witam.
Tak sobie w ramach nauki czytam o modułach wprowadzonych w Javie 9 i zacząłem się zastanawiać czy jest to lepsze/częściej wykorzystywane niż np. moduły mavenowe lub po prostu wydzielenie modułu do pakietu javowego i wystawienie jakieś publicznej fasady? Jak to wygląda na waszych projektach? Na któreś z tych podejść powinienem postawić jako osoba ucząca się Javy ?
0
0
Kiedyś usłyszałem że moduły Javy 9 są totalnie nieprzydatne zwykłemu developerowi i są po to żeby uprościć życie twórcom JVM. Ewentualnie po to jakbyś chciał swój program w Javie owrapować w dedykowaną JVM i zbudować jeden plik wykonywalny.
Na tym swoją naukę o modułąch Javy 9 zakończyłem, ale jak ktoś zna zalety dla zwykłego projektu to chętnie poczytam
5
ZTCP to moduły z Javy 9+ dodają coś co można by nazwać nowym zakresem widoczności pakietów i znajdujących się w nich klas. Standardowo Java ma public, protected, private i package private (to ostatnie jest domyślne, bez żadnego słowa kluczowego). Problem z tym jest taki, że dużo klas jest public i z tego powodu trudno jest poukrywać klasy, np. w bibliotece, przed niewłaściwym użyciem. Moduły z Javy 9+ dodają exporty i importy w module-info.java i dzięki temu, przy całkowitym przełączeniu się z klasycznego classpatha na ten modułowy* , można ukryć część publicznych klas (tzn. z modyfikatorem public) przed innymi modułami.
* chyba, być może nie trzeba się całkowicie przerzucać na moduły Javy 9+. Nie drążyłem tematu.
C# ma zasięg typu internal https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/internal i moduły Javy 9+ dodają właśnie coś podobnego, ale mechanizm jest inny, tzn. widoczność określa się w innym miejscu (w module-info.java zamiast bezpośrednio przy klasie).
Mimo wszystko mało kto się na te moduły Javy 9+ przerzuca, oprócz oczywiście samego JRE / JDK. JPMS (to pełna nazwa tych modułów Javy 9+) można używać wraz z klasycznym classpathem, więc obstawanie przy starym formacie nie redukuje funkcjonalności.
3
Moduły Javy (JPMS) mają się nijak do paczek Maven'a/Gradle. Niestety... W praktyce powoduje to sporo problemów, sporo bibliotek nie definiuje module-info itp. Trzeba definiować zależności x2 (w Mavenie i module-info), testy ssą bo java nie udostępnia testom prywatnych części modułu. Jednym słowem tragedia i masakra...
Największą zaletą JPMS'a jest możliwość generowania obrazów JVM'a skrojonych pod aplikację. Ma to znaczenie w dobie obrazów Dockerowych i IoT bo można zaoszczędzić z 200MB. Nie licząc szybszego startu aplikacji i większego bezpieczeństwa.
Co do architektury to już w mavenie można było sobie zdefiniować paczkę foo-api ze scopem compile i paczke foo-implementation ze scopem provided, i tym samym mieć prywatną implementację. Problem z tym podejściem jest taki że nie pozwalało ono unikać konfliktów na classpath'ie który był globalny. Użycie nazw związanych z domenami internetowymi generalnie rozwiązywało ten problem (org.google na przykład). Moduły pomogą tutaj bo część prywatna jest po prostu niedostępna. Natomiast to czego moduły nie zapewniają to jednoczesna obecność kilku wersji tego samego modułu w pamięci (czyli wersjonowanie). Trochę szkoda bo .NET ma od początku taką funkcjonalność.
Pisałem ostatnio trochę małych apek w JavaFX wszystko w wersji modulowej, możesz popatrzeć jakie tam są problemy: https://github.com/marcin-chwedczuk/rfid/