Tak to jest… zawsze jak nie ma mnie tydzień, to nazbiera się tematów i kolejna edycja jest baaardzo długa. Miłej lektury/
1. Jak Netflix używa Javy w 2024?
Kojarzycie ByteByteGo? Pewnie tak, bo najpopularniejszy substackowy newsletter na świecie, omawiający tematy i trendy w projektowaniu systemów na dużą skalę, autorstwa twórców bestsellerowej serii książek „System Design Interview”. Osobiście jestem wielkim fanem, nawet nie tylko ze względu na wiedzę, która jest tam prezentowana (bo pokrywane są jednak w większości dosyć „laboratoryjne” przypadki architektur), ale ze względu na formę. Całość jest bardzo przystępna i mocno wizualna, w związku z tym nawet w zagadnieniach, w których w miarę się orientuje lubię zajrzeć, co zostało przez nich opisane. Dlatego kiedy opublikowali tekst Evolution of Java Usage at Netflix stwierdziłem, że jest to idealna wręcz okazja, żeby się ByteByteGo z Wami podzielić.
O samym Netflixie zawsze krążyło wiele mitów, bo pewnie w formatywnym dla wielu z nas okresie to właśnie z ich rozwiązań, takich jak RxJava, Nebula czy Hystrix, uczyliśmy się (w tym na błędach) jak podchodzić do architektury Microserwisowej, sam pamiętam moją fascynację nimi gdzieś w okolicach 2016 roku. Jednak już w Maju 2022 Paul Bekker tłumaczył na Twitterze, że tak naprawdę RxJava to już, co opisywałem w JVM Weekly #4 (ale ten czas leci). Ten sam Paul w zeszłym roku na konferencjach Spring One i Infoq opowiadał o ewolucje nie tylko netflixowego podejścia do Javy, ale też architektury – samą prezentacje możecie zobaczyć tutaj:
Wracając do publikacji ByteByteGo, ta wyraźnie bazuje na rzeczonej prezentacji Paula, omawiając ewolucję podejścia do Javy w Netflix i prezentując, jak dynamicznie zmieniała się architektura firmy, aby sprostać rosnącym wymaganiom technologicznym i operacyjnym. Netflix dalej zdecydowanie stawia na Java, jednak z biegiem lat, stack Java w Netflix przeszedł znaczące zmiany, odchodząc od monolitycznej architektury w kierunku bardziej zdecentralizowanej i elastycznej architektury mikroserwisowej. Artykuł opisuje przejście od użycia skryptów Groovy w ramach wzorca backend dla frontendu (BFF) – dalej pamiętam czasy, gdy Netflix promował własne rozwiązanie Falcor – do wprowadzenia GraphQL Federation, co stanowiło odpowiedź na potrzebę bardziej efektywnego zarządzania zapytaniami i danymi. Ta zmiana pozwoliła na znaczne zmniejszenie redundancji API i nadmiarowego pobierania danych, co jest kluczowe przy obsłudze różnorodnych urządzeń końcowych klientów (a Netflix ma tych klientów zatrzęsienie).
Ponadto, artykuł porusza kwestię ewolucji wersji Java w Netflix, przechodząc od Java 8 do nowszych wersji jak Java 17 i 21, co przyczyniło się do lepszego wykorzystania procesora i redukcji kosztów operacyjnych – ogólnie warto. Firma też wystandaryzowała się w koło Spring Boota, przy równoczesnym wykorzystania zalet szerokiej społeczności open-source. Ogólnie jeśli lubicie podejmować decyzje technologiczne na bazie tego, co BigTechy pokazują na konferencjach (nie polecam) – całość jest naprawdę ciekawa. Nawet jeśli zdroworozsądkowo nie użyjecie zawartych w tekście lekcji, to całość pokaże jak taka ewolucja przebiega w dużej organizacji.
Zainstaluj teraz i czytaj tylko dobre teksty!
2. Nowe Projekty w JDK, czyli jak Minecraft pcha Javę do przodu
Tytuł obecnej sekcji (i całej edycji) może jest odrobinkę naciągnięty, ale nie mogłem sobie darować. Wychowałem się w przekonaniu, że Java nie nadaje się w żadnym razi do gier. Dlatego uwielbiam każdą sytuację, gdy mogę uświadomić wszystkim, że Minecraft, pozostający jedną z najpopularniejszych gier na świecie działa na JVM. Dumny ekosystem dba o swój klejnot koronny, a ten mu się odwdzięcza jak może. Jednak zanim dojdziemy do Minecrafta, w tej sekcji poświęconej nowym projektom zajmiemy się poważnym tematem, dla poważnych ludzi – bezpieczeństwem.
Trochę kontekstu: Java Cryptography Architecture (JCA) i Java Cryptography Extension (JCE) są dwoma głównymi bibliotekami kryptograficznymi w Javie, które współpracują w celu zapewnienia szerokiego zakresu funkcji kryptograficznych. JCA, będąca częścią Corę API Javy, oferuje podstawowe funkcjonalności kryptograficzne, natomiast JCE rozszerza te możliwości, wprowadzając zaawansowane operacje kryptograficzne. Ta ostatnia biblioteka były kiedyś przedmiotem amerykańskich regulacji eksportowych, nie mogła więc stać się oficjalną częścią JDK, ale z czasem ograniczenia te zostały złagodzone, co pozwoliło na ich wspólną integrację z Java SE. Z tego względu rozgraniczenie między nimi nie jest już tak wyraźne, przyszłe zmiany w regulacjach mogą ponownie wpłynąć na ich dostępność i funkcjonalność – a że żyjemy w dosyć niespokojnych czasach, to ja bym traktował to ryzyko jako niezerowe.
Przejdźmy jednak do głównej zapowiedzi. Projekt Brisbane, bo o nim mowa, to inicjatywa mająca na celu stworzenia implementacji JCE zgodnego ze standardem FIPS 140, przeznaczonego specjalnie dla regulowanych środowisk w Stanach Zjednoczonych. Projekt planuje wykorzystać Foreign Function & Memory API do stworzenia rappera nad biblioteką OpenSSL, która została zweryfikowana zgodnie z normą FIPS 140, zapewniając jej poprawne użycie. Brisbane zamierza w ten sposób dostarczyć rozwiązanie kryptograficzne spełniające rygorystyczne wymagania bezpieczeństwa, jednocześnie integrując się płynnie z aplikacjami JVM-owymi.
FIPS 140 (Federal Information Processing Standard Publication 140) to standard rządowy USA, który ustanawia wymagania bezpieczeństwa dla modułów kryptograficznych używanych w federalnych systemach informatycznych. Dzięki zgodności ze standardami FIPS 140, OpendJDK (bo kompatybilność z FIPS 140 była już dostępna wcześniej min. w ramach Oracle Cloud) będzie mogła być używana w środowiskach wymagających najwyższego poziomu ochrony danych, takich jak wrażliwe operacje sektorów rządowego i finansowego.
No dobra, ale teraz pora przejść do wyjaśnienia, o co chodzi mi z tym przytoczonym wcześniej Minecraftem. Projekt Wakefield to inicjatywa mająca na celu integrację obsługi linuxowego serwera wyświetlania Wayland w JDK. Wayland ma zastąpić przestarzały protokół serwera wyświetlania pulpitu X11, opracowany w latach 80., nowoczesnym podejściem umożliwiającym renderowanie po stronie klienta oraz systemem okien tak zwanego pulpitu kompozytowego, stając się domyślną technologią serwera wyświetlania na licznych dystrybucjach Linuxa, takich jak RHEL 8, OL 8 i Ubuntu 21.04. Projekt Wakefield ma dwa główne cele: krótko- do średnioterminowe rozwiązanie dla JDK działającego na Waylandzie w trybie kompatybilności X11 oraz średnio- do długoterminowe rozwiązanie, polegające na uruchomieniu JDK jako natywnego klienta Wayland. Drugi cel jest głównym celem projektu, jednak jego realizacja jest znacznie bardziej skomplikowana i zajmie wiele lat, dlatego niezbędne jest również osiągnięcie krótkoterminowego celu.
Znaczenie Wayland dla Javy, szczególnie w kontekście gier (w tym Minecrafcie), bo te wymagają solidnej wydajności graficznej i kompatybilności systemowej. Minecraft, wraz z innymi grami opartymi na Javie, opiera się na stabilnej i wydajnej architekturze serwera wyświetlania, aby zapewnić odpowiednią płynność. Przenosząc Javę do natywnego środowiska Wayland, deweloperzy mogą wykorzystać lepsze możliwości Waylanda w zakresie obsługi renderowania po stronie klienta i kompozycji, co potencjalnie zwiększa wydajność graficzną na systemach Linux, co zapewni zapewnienia, że popularne aplikacje Javy, takie jak Minecraft, nadal będą działały optymalnie na tych platformach, bez polegania na przestarzałych lub mniej wydajnych protokołach oraz warstwach kompatybilności.
I Minecraft się odwdzięcza. Wprowadzenie najnowszego snapshotu Minecrafta, oznaczonego numerem 24W14A, wprowadza istotne zmiany techniczne, które mogą znacząco przyczynić się do dalszej popularności nowych wydań JDK. Od nowej aktualizacji, Minecraft (w swojej edycji Javowej) wymaga bowiem zainstalowania Java 21, korzystając z dystrybucji Java od Microsoftu (czy ktoś się dziwi?). Dodatkowo, gra teraz obsługuje tylko 64-bitowe systemy operacyjne (bo i dla przypomnienia – JDK też niedługo pozbędzie się trybu 32-bitowego).
Może się okazać, że to jedno z największych pojedynczych wydarzeń promujących adopcje nowego LTSa.
Zainstaluj teraz i czytaj tylko dobre teksty!
3. Release Radar
6-Month Roadmap for Java on Azure Tools
Jako, że było o Microsofcie, to zaczniemy sobie od publikacji półrocznej roadmapy dla Java on Azure Tooling, przedstawioej przez Jialuo Gana. Całość daje nam wgląd w plany Microsoftu i tylko podkreśla, jak strategicznym obszarem stała się dla firmy Java.
Istotne aktualizacje obejmują integrację z najnowszymi usługami Azure, takimi jak Azure Functions, Azure Web App i Azure Cosmos DB, z konkretnymi ulepszeniami takimi jak wsparcie Flex Consumption oraz aktualizacje wersji środowiska wykonawczego Java. Dodatkowo, kładziony jest duży nacisk na budowanie aplikacji natywnych dla chmury za pomocą usług konteneryzowanych, takich jak Azure Container Apps (ACA) i Azure Kubernetes Service (AKS).Planowane są dalsze ulepszenia, mające na celu pomoc programistom w tworzeniu inteligentnych aplikacji przy użyciu usługi Azure OpenAI, z wsparciem dla nowych modeli takich jak Completions i DALL-E (tutaj chyba brak zaskoczeń).
Trwają również prace nad integracją Azure SDK Build Tool z zestawem narzędzi Azure i wtyczką Maven, mające na celu pomoc programistom w zapewnieniu poprawnego użycia Azure SDK i zarządzaniu zależnościami, co nie zawsze było takie oczywiste. W tym samym celu usprawniono również dostępne mechanizmy autoryzacji. Obok ulepszeń technicznych, zespół Azure zobowiązał się do aktualizacji dokumentacji i zmniejszenia liczby błędów.
Visual Studio Code March Update
W ostatniej edycji dość szeroko rozpisywałem się o tym, jak użytecznym narzędziem dla programistów Java stało się Visual Studio Codę, przyglądnijmy się więc nowościom, jakie jego twórcy mają dla programistów Javy.
W marcowej aktualizacji Visual Studio Code dla Java wprowadzono szereg nowych funkcji dla Spring Boot. Znaczącą nowością jest opcja podglądu refaktoryzacji dostępna podczas aktualizacji wersji, która pozwala na automatyczne uaktualnienie projektów do najnowszej wersji Spring Boot z możliwością podglądu zmian przed ich zastosowaniem. Dodano także możliwość bezpośredniego dodawania starterów Spring Boot poprzez plik pom.xml, co ułatwia zarządzanie zależnościami. Ponadto, użytkownicy mogą teraz na bieżąco zmieniać poziomy logowania w działającej aplikacji dzięki nowej komendzie w palecie narzędzi, co jest skuteczne tylko podczas bieżącej sesji uruchomieniowej.
Nowością w stabilnej wersji Visual Studio Code jest również możliwość przeprowadzenia testów z pokryciem – wcześniej było to dostępne tylko w wersji Insider. Funkcja ta, wspierana przez bibliotekę Jacoco i najnowsze API do pokrycia testów, pozwala na szczegółową analizę pokrycia kodu bezpośrednio w edytorze. Aby korzystać z tych wszystkich nowości, należy zainstalować najnowszą wersję Extension Pack for Java, a część z powyższych nowości dotyczących Springa wymaga zainstalowanie wyspecjalizowanej dla niego paczuszki.
A jak już o IDE mowa…
Intellij Idea 2024.1
Zwykle IntelliJ IDEA dostaje w tym przeglądzie swoją własną sekcje, ale jako, że o niektórych zmianach wspominałem już przy okazji poprzednich przeglądów, dzisiaj będzie nieco krócej, co nie znaczy że nie ma nic ciekawego do opisania. Nowa wersja środowisko IDE w pełni wspiera bowiem najnowsze funkcje Javy 22, co opisane zostało w całym poświęconym temu poście. Inne usprawnienia specyficzne dla Javy obejmują wprowadzenie wstrzykiwania języków do szablonów stringów, nowe inspekcje i szybkie poprawki. Dodatkowo, poprawiono UX pracy z bibliotekami wielowersyjnymi JAR.
Dla programistów Kotlin i Scala, IntelliJ IDEA 2024.1 wprowadza znaczące ulepszenia. Środowisko IDE zawiera nowy tryb Kotlin K2, wykorzystujący wbudowany kompilator Kotlin K2 do poprawy analizy kodu Kotlin, oraz domyślnie stosuje oficjalny przewodnik stylu Kotlin jako opcję formatowania. Dla Scala, wsparcie dla Scala 3 zostało ulepszone, w tym lepsze rozpoznawanie mieszanych modyfikatorów, poprawiona obsługa wcięć i ulepszona obsługa debuggera. Dodatkowo, IntelliJ IDEA ulepszyło obsługę statycznych importów w Kotlinie i dodało nowe możliwości pracy ze Scala, takie jak ulepszone Scaladoc i wyskakujące okienka z dokumentacją.
Poza funkcjami specyficznymi dla języka, IntelliJ IDEA Ultimate 2024.1 oferuje szereg aktualizacji mających na celu poprawę ogólnego produktywności użytkownika. IDE usprawniło klienta HTTP, integruje wsparcie dla OpenRewrite (ostatnio o tym projekcie Adam Bien w swoim podcaście rozmawiał z Jonathanem Schneiderem, polecam) do refaktoryzacji oraz wprowadza aktualizacje wsparcia dla Terraform. Narzędzia obsługi baz danych również zostały znacznie ulepszone o takie opcje jak filtrowanie lokalne w edytorze danych, usprawnione wykonanie zapytań i ulepszone wsparcie dla modułów Redis. Ponadto, IntelliJ wprowadziło ulepszenia w systemach kontroli wersji z nowymi trybami przeglądu kodu dla GitHub i GitLab oraz szeregiem innych ulepszeń VCS.
A jak już wspomnieliśmy K2…
Kotlin 2.0 RC
W Kotlin 2.0 właśnie wkroczyła w fazę Release Candidate, której to kolejne iteracje będą stopniowo umożliwiały dostęp do kolejnych funkcjonalności. Daje Wam znać głównie informacyjnie, ale wszystko wskazuje na to, że twórcy języka Kotlin szykują coś wyjątkowego na zbliżającą się KotlinConf 2024.
JKube 1.16
JKube to narzędzie ułatwiające integrację projektów Java z Kubernetes, automatyzujące proces tworzenia zarówno plików Dockerfile, jak i generując potrzebne manifesty Kubernetes. Zintegrowane z Mavenem i Gradle, umożliwia łatwe wdrażanie, zarządzanie i debugowanie aplikacji w środowisku Kubernetes. JKube eliminuje konieczność ręcznej konfiguracji Docker i Kubernetes, wspiera zaawansowane funkcje Kubernetes jak health checks czy autoscaling, ale też tworzenia obrazów kontenerów za pomocą strategii budowania Docker, S2I lub Jib.
W najnowszej wersji JKube, 1.16, użytkownicy dostali nową strategię budowania obrazów kontenerów za pomocą Cloud Native Buildpacks, co pozwala na przekształcenie kodu źródłowego w gotowy do uruchomienia obraz aplikacji – ostatnio wspominałem o tym standardzie w kontekście nowej wersji GraalVM. Dodano także nową funkcję lintowania wykresów Helm, którą można uruchomić za pomocą prostego polecenia Maven lub Gradle, aby zbadać wygenerowane wykresy Helmowe pod kątem ewentualnych problemów. Zaktualizowano również obrazy bazowe i wprowadzono rekomendowane etykiety Kubernetes, co razem z poprawkami błędów i drobnymi usprawnieniami czyni z JKube jeszcze bardziej użyteczne narzędzie…
JobRunr
Prywata: Mimo, że Quartz pozostaje chyba najpopularniejszym rozwiązaniem do schedulingu zadań w tle, to moją ulubioną, rekomendowaną biblioteka pozostaje JobRunr, który łatwo integruje się z popularnymi frameworkami Java i obsługuje różne metody zarządzania trwałością zadań. Dodatkowo, oprócz możliwość zarządzania bardziej skomplikowanymi harmonogramami i elastyczność, JobRunr zapewnia również szczegółowe monitorowanie i zarządzanie stanami zadań za pomocą kompleksowego pulpitu nawigacyjnego, co przy bardziej skomplikowanych systemach jest naprawdę nieocenione. Dlatego też wydanie jego nowego wydania bardzo mnie prywatnie cieszy.
Wersja 7.0.0 JobRunr i JobRunr Pro wprowadza szereg bardzo ciekawych nowości. Zacznijmy od wersji bazowej, która przynosi wsparcie dla Wirtualnych Wątków i konfigurowalne okresy zamykania serwera zadań. Dodatkowe ulepszenia obejmują optymalizację przetwarzania zadań za pomocą wielu wątków, lepsze zarządzanie migracjami bazy danych oraz lepsze informowanie jeśli chodzi o wąskich gardłach jeśli chodzi o wydajnoś. Aktualizacja poprawia również wydajność systemu poprzez wprowadzenie identyfikatorów UUID opartych na czasie dla identyfikacji zadań.
Ciekawe rzeczy pojawiają się też w wersji Pro celującej w firmy Enterprise, która wprowadza masę nowości do pulpitu nawigacyjnego – wsparcie OpenId, czy też opcje zgodności z GDPR/HIPAA umożliwiające ukrywanie wrażliwych danych zadań. „Profesjonalni” użytkownicy otrzymali również zaawansowane możliwości ograniczania przepustowości przetwarzania zadań oraz możliwość dostosowania tabel z zadaniami poprzez dodatkowe kolumny i konfigurowalną widoczność, co przyda się sytuacji, gdy chcemy nasz scheduling pointegrować z innymi systemami firmowymi.
To nie wszystkie zmiany, bo tych jest naprawdę dużo. Jeżeli więc używacie JobRunr, zachęcam do przeglądnięcia Release Notes.
PS: Dzisiaj wyszło długo, ale to dlatego, że tydzień temu byłem na ostatniej prostej przygotowywania mojego nowego konferencyjnego talka Digging for Truffles – Unveiling the Mysteries of GraalVM’s Least Understood Component na potrzeby konferencji 4Developers. Jeżeli będę miał go okazję gdzieś opowiadać za granicą, na pewno będę informować