Wiele organizacji planujących migrację z Oracle Java SE będzie się zastanawiać, jak długo potrwa ten proces. Nie ma jednak uniwersalnej odpowiedzi na to pytanie. Czas potrzebny na migrację zależy od co najmniej kilku zmiennych specyficznych dla organizacji.
Jedną z tych zmiennych są cele związane z migracją firmy – osiągnięcie niektórych celów zajmuje więcej czasu niż innych. Na przykład, jeśli celem jest jak najszybsze całkowite przejście z oprogramowania Oracle Java, plan migracji będzie inny niż w przypadku organizacji, która szuka przede wszystkim wsparcia dla starszych aplikacji ze starszymi wersjami Javatakich jak Java 6 i 7, i wolałby podejście etapowe, rozłożone na dłuższy okres.
Przygotowanie do migracji z Oracle Java SE
Pierwszym etapem migracji jest inwentaryzacja środowiska Java, która często stanowi najbardziej czasochłonną część zestawu Java Development Kit (JDK) migracja ze względu na różnorodność używanych wersji JDK. Zwykle po wdrożeniu nowej aplikacji korzysta ona z najnowszej wersji pakietu JDK dostępnej w danym momencie i nadal z niej korzysta, nawet po wydaniu nowszych wersji języka Java. Jest to całkiem logiczne, ponieważ zostało przetestowane z wdrożoną wersją.
Zakładając, że aplikacja działa bezproblemowo, nie ma konieczności aktualizacji jej wersji JDK. Aktualizacja jest wymagana tylko wtedy, gdy poprawki zabezpieczeń i poprawki błędów nie są już dostępne dla używanej wersji i istnieją wątpliwości dotyczące wydajności aplikacji lub znana luka w zabezpieczeniach, którą należy zaradzić.
Aby utworzyć pełną inwentaryzację użycia JDK, organizacje muszą sprawdzić każdą maszynę w swoim majątku, na której działają dowolne aplikacje oparte na wirtualnej maszynie Java (JVM). Może to być proste, jeśli do monitorowania wykorzystania oprogramowania wykorzystywane są narzędzia do zarządzania zasobami IT (ITAM). Wiele przedsiębiorstw wdraża te narzędzia, aby mieć pewność, że przestrzegają warunków licencji. Narzędzia te mogą szybko wygenerować raport pokazujący, które komputery mają zainstalowaną wersję Java. Skrypty są również dostępne u dostawców takich jak Azul, które ułatwiają bezproblemową inwentaryzację maszyn JVM.
Następnie organizacja powinna zacząć myśleć o potencjalnych problemach, które mogą się pojawić na podstawie tego, co zostało wykryte podczas inwentaryzacji.
Na przykład bardzo często użytkownicy kupują aplikacje zamiast je rozwijać. Brak konieczności tworzenia i utrzymywania oprogramowania na zamówienie we własnym zakresie może być bardzo opłacalny. Wiele takich aplikacje korzystające z języka Java określi wymaganą wersję JDK i ewentualnie minimalny poziom aktualizacji wersji – nie różni się to od sposobu, w jaki inne aplikacje określają minimalną wersję systemu Windows lub Linux.
Użytkownik musi pozyskać pakiet JDK i udostępnić go aplikacji. Dostawcy aplikacji często stwierdzają w swojej dokumentacji, że będą wspierać aplikację tylko wtedy, gdy będzie używana z właściwym pakietem JDK. Jest to rozsądne z punktu widzenia twórcy aplikacji, ponieważ może pomóc w wyeliminowaniu problemów spowodowanych użyciem nieaktualnych lub nieodpowiednich środowisk wykonawczych Java. Ponieważ pakiet Oracle JDK był w przeszłości tak wszechobecny, wielu dostawców aplikacji stwierdziło, że tylko pakiet Oracle JDK będzie kwalifikował się do wsparcia.
Ostatni zmiany w licencjonowaniu i cenach Oracle JDKoznacza to jednak, że użytkownicy coraz częściej wymagają wsparcia w przypadku korzystania z alternatywnych pakietów JDK. Wielu dostawców aplikacji będzie teraz zapewniać wsparcie, jeśli aplikacja będzie działać na kompilacji OpenJDK z certyfikatem Technology Compatibility Kit (TCK). Ponieważ mogą mieć pewność, że takie dystrybucje będą funkcjonalnie identyczne z pakietem Oracle JDK, nie muszą się martwić testowaniem wielu dystrybucji w swoich aplikacjach.
Czasami aplikacja będzie stwierdzać, że jest to pewne Dystrybucje OpenJDK są ważne w przypadku wsparcia, ale nie tego, z którego organizacja chce skorzystać. W takim przypadku użytkownicy powinni skontaktować się z dostawcą aplikacji, aby dodać wymaganą dystrybucję do swojej listy. Dostawca nie powinien mieć zastrzeżeń, o ile posiada certyfikat TCK.
W każdej dużej organizacji, w której używanych jest wiele aplikacji Java, aplikacje będą miały różnych właścicieli. Planując pomyślną migrację, konieczne jest uwzględnienie wszystkich zainteresowanych stron, czyli wszystkich właścicieli aplikacji, którzy muszą korzystać z nowego środowiska wykonawczego Java i/lub obawiają się o kondycję swoich aplikacji.
Migracja do OpenJDK
OtwórzJDK dystrybucje nie obsługują aktualizacji na miejscu — zastosowanie aktualizacji JDK wymaga zainstalowania zupełnie nowego pakietu JDK. Oznacza to, że proces instalacji migracyjnej można traktować dokładnie tak samo, jak wdrażanie nowej aktualizacji, z tą różnicą, że instaluje aktualizację Zulu JDK zamiast aktualizacji Oracle JDK.
O ile nie wystąpi konkretny błąd powodujący problemy ze stabilnością aplikacji, użytkownicy nie będą widzieli pilnej potrzeby przejścia na nową wersję Java, nawet jeśli używają dość starej wersji. Jednakże z administracyjnego punktu widzenia zawsze warto zainstalować najnowszą aktualizację podczas migracji do nowej dystrybucji OpenJDK, aby zachować najwyższy poziom bezpieczeństwa aplikacji.
W zdecydowanej większości przypadków proces aktualizacji jest prosty i bezproblemowy. Czasami jednak aktualizacja zawiera zmiany, które mogą zmienić zachowanie aplikacji.
Przykład Tomcata
Spójrzmy na przykład wykorzystujący bardzo powszechnie używane Silnik serwletów Apache Tomcat. Załóżmy, że mamy Tomcat 8 działający na Oracle JDK 8u202. Nie jest to najnowsza wersja Tomcata, ale doskonale sprawdza się w naszej aplikacji, więc nie była aktualizowana. Mamy uruchomiony serwlet, który pobiera dane od klienta, wykonuje zapytanie w bazie danych MySQL i zwraca wynik.
Dla naszej migracji, instalujemy aktualizację Zulu 8 372 i restartujemy serwer. Jednak gdy próbujemy skorzystać z aplikacji, pojawia się komunikat o błędzie informujący nas o awarii łącza komunikacyjnego. Nie ma to nic wspólnego z przejściem z Oracle na Zulu.
Zamiast tego wynika to ze zmiany wprowadzonej w aktualizacji JDK 8 291 z października 2021 r. W tej aktualizacji zmieniono domyślne ustawienia Transport Layer Security (TLS), aby domyślnie wyłączyć TLSv1.0 i TLSv1.1. Dlatego też, aby aplikacja działała jak dotychczas, musimy zmodyfikować plik jre/lib/security/java.security i usunąć odniesienia TLS z ustawienia algorytmów jdk.tls.disabled.
Kiedy coś takiego się wydarzy, ważne jest, aby sprawdzić, czy przyczyną problemu jest użycie innej aktualizacji JDK, a nie innej dystrybucji. W takich przypadkach niezwykle korzystne może być posiadanie komercyjnego dostawcy wsparcia, który może zapewnić starsze aktualizacje. Wystarczy zainstalować ten sam poziom aktualizacji JDK, a następnie ponownie przetestować aplikację. W naszym przykładowym przypadku zespół pomocy technicznej Azul byłby w stanie podać szczegółowe informacje na temat zmian konfiguracyjnych wymaganych do rozwiązania problemu.
Po zainstalowaniu nowego JDK musimy dokonać niezbędnych zmian, aby przełączyć aplikacje na jego obsługę. Na przykład może być konieczna zmiana zmiennej środowiskowej JAVA_HOME i programów uruchamiających używanych dla poszczególnych aplikacji, takich jak silnik serwletu Tomcat. Najbezpieczniejszą opcją jest zmiana tej zmiennej środowiskowej na wszystkich migrowanych komputerach.
Po instalacji powinniśmy przetestować wszystkie aplikacje, które zostały przełączone na nowy JDK, aby upewnić się, że działają poprawnie. Użytkownicy prawdopodobnie nie zaobserwują żadnego innego zachowania, chyba że pomiędzy aktualizacjami nastąpiły zmiany.
Testowanie w celu sprawdzenia prawidłowego zachowania
Proces testowania będzie się znacznie różnić w zależności od aplikacji. Aplikacje opracowane wewnętrznie mogą mieć rozbudowane testy regresyjne, które mogą w pełni przetestować wszystkie części aplikacji w celu sprawdzenia prawidłowego zachowania.
Aplikacje innych firm (open source lub komercyjne) mogą mieć zestaw standardowych testów, które można uruchomić. Jeśli nie, doświadczony użytkownik powinien uruchomić aplikację i wypróbować jak najwięcej aspektów funkcjonalnych.
Gdy wszystkie testy przejdą pomyślnie dla każdego użytkownika, migracja zostanie zakończona. Organizacja będzie teraz miała silną pozycję niezbędną do utrzymania najwyższego poziomu bezpieczeństwa i stabilności oprogramowania Java, często wyższego niż dotychczas. Ponadto będzie miał jasny obraz tego, gdzie jest używane środowisko wykonawcze Java, i będzie miał więcej doświadczenia w aktualizowaniu maszyn do najnowszej aktualizacji Java.
Artykuł ten powstał na podstawie fragmentu Migracja OpenJDK dla manekinów, wydanie specjalne Azulautorstwa mistrza Java Simona Rittera.