Java Academy · Lekcja

Migracja do modułów

Moduły automatyczne i nienazwane

Lekcja 4 z 413 kroki

Migracja do modułów to bezpłatna lekcja Java Academy na CoddyKit. To lekcja 4 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Java Academy, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Java Academy zawiera 4 lekcji w sumie.

Modularyzacja istniejącego kodu

Niewiele projektów przyjmuje moduły od pierwszego dnia. JPMS zaprojektowano z myślą o stopniowej migracji, umożliwiając współistnienie classpath i ścieżki modułów.

Kluczowe znaczenie mają moduły automatyczne i moduł nienazwany.

Moduł nienazwany

Wszystko, co jest ładowane z classpath, należy do jednego modułu nienazwanego. Odczytuje on każdy inny moduł i eksportuje wszystkie swoje pakiety.

Jest to pomost, który pozwala starszemu kodowi korzystającemu z classpath nadal działać.

Nazwany moduł nie może odczytywać nienazwanego

Kluczowa zasada: jawnie nazwany moduł nie może zależeć od modułu nienazwanego. Nie można zapisać requires dla kodu znajdującego się na classpath.

Dlatego migrację należy przeprowadzać oddolnie: najpierw zmienić sposób reprezentacji zależności.

Moduły automatyczne

Umieszczenie zwykłego, niemodularnego pliku JAR na ścieżce modułów powoduje przekształcenie go w moduł automatyczny. Otrzymuje on automatycznie wyznaczoną nazwę, odczytuje wszystkie inne moduły i eksportuje wszystkie swoje pakiety.

Dzięki temu nazwane moduły mogą używać requires dla pliku JAR, który nie ma jeszcze pliku module-info.

Pochodzenie nazwy

Nazwa modułu automatycznego jest wyznaczana w następującej kolejności:

Wpis Automatic-Module-Name w manifeście pliku JAR, jeśli istnieje
W przeciwnym razie z nazwy pliku JAR (po usunięciu wersji i zamianie łączników na kropki)

Stabilne nazwy mają znaczenie

Autorzy bibliotek powinni dodać Automatic-Module-Name do manifestu przed pełną modularyzacją. Zapewnia to stabilną nazwę modułu, dzięki czemu klauzule requires w modułach korzystających z biblioteki zachowają poprawność po wprowadzeniu właściwego pliku module-info.

Automatic-Module-Name: com.example.json

Strategia od góry

Zalecane podejście w przypadku własnej aplikacji:

Pozostawić zależności jako moduły automatyczne na ścieżce modułów
Najpierw dodać plik module-info.java do głównego modułu aplikacji
Zadeklarować requires dla nazw tych modułów automatycznych

Przykładowy etap migracji

Załóżmy, że plik guava-32.jar znajduje się na ścieżce modułów jako moduł automatyczny com.google.common. Moduł aplikacji może już zawierać dla niego deklarację requires.

module com.example.app {
    requires com.google.common;
    exports com.example.app.api;
}

Problem podzielonych pakietów

System modułów zabrania dwóm modułom zawierać ten sam pakiet. Starsze biblioteki, które dzielą pakiet między pliki JAR, powodują błędy.

Można temu zaradzić, scalając pliki JAR, używając --patch-module lub aktualizując biblioteki do wersji rozwiązujących problem podziału.

Problemy z dostępem refleksyjnym

Frameworki wykonujące głęboką refleksję mogą po modularyzacji zgłaszać błąd InaccessibleObjectException. Należy dodać dyrektywy opens lub tymczasowo użyć flagi uruchomieniowej --add-opens.

Przydatne narzędzie jdeps

Narzędzie jdeps analizuje pliki JAR, raportuje zależności, wykrywa użycie wewnętrznych API JDK, a nawet może wygenerować proponowany plik module-info.java za pomocą jdeps --generate-module-info.

Warto uruchomić je w pierwszej kolejności, aby zaplanować migrację.

Szybkie sprawdzenie

Proszę przypomnieć sobie, w jaki sposób zwykły plik JAR otrzymuje tożsamość modułu.

Odpowiedz w interaktywnej lekcji

Podsumowanie

Poznali Państwo techniki migracji:

Kod z classpath znajduje się w module nienazwanym; nazwane moduły nie mogą zawierać dla niego deklaracji requires
Zwykłe pliki JAR na ścieżce modułów stają się modułami automatycznymi
Należy ustawić Automatic-Module-Name, aby uzyskać stabilne nazwy
Należy zwrócić uwagę na podzielone pakiety i dostęp refleksyjny; do planowania warto użyć jdeps

Na tym kończy się kurs JPMS.

Bezpłatny start

Ucz się Java dzięki korepetycjom AI — za darmo

Pisz i uruchamiaj kod w przeglądarce, otrzymuj natychmiastową pomoc od korepetytora AI dostępnego 24/7 i kontynuuj naukę w sieci lub w aplikacji.

Kursy: 104
Lekcje: 374

Zacznij naukę bezpłatnie Wyświetl pełny kurs

Często zadawane pytania

Czy lekcja „Migracja do modułów” jest bezpłatna?

Tak — pełny tekst „Migracja do modułów” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Java Academy, przejdź na CoddyKit PRO. Kurs Java Academy zawiera 4 lekcji w sumie.

Co nauczysz się w „Migracja do modułów”?

Moduły automatyczne i nienazwane Ćwiczysz Java Academy z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Java Academy?

Nie wymagamy żadnego doświadczenia. Java Academy w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 4 z 4.

Ile czasu zajmuje lekcja „Migracja do modułów”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Java Academy?

Tak. Każda lekcja Java Academy zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

← Powrót do Java Academy