W dzisiejszej edycji dzielimy się „sneak peakiem” tego co w Javie 17. Oprócz tego ogłoszenia dotyczące OSGI oraz pomoc w wyborze jednego z nowych Javowych Webowych Frameworków.
Zacznijmy od najważniejszego:
A teraz do konkretów
1. Micronaut vs Quarkus – którego wybrać ? ⚔️
Przez kupę lat w świecie JVMowych Frameworków był Spring Boot, daleko w tyle implementacje Java EE, a potem długo, długo nic. Gdzieś tam majaczył Spark (nie mylić z Apache Spark), jakąś tam niszę zajmował Dropwizard, pasjonaci mogli bawić się Grailsami… i to by było na tyle.
Sytuacja ostatnimi czasy zmieniła się diametralnie. Wraz z premierą Micronauta od Object Computing (którzy wcześniej stworzyli wspomniane przed momentem Grails) zauważyć możemy ponowne zainteresowanie wykrojeniem sobie kawałka smakowitego javowego tortu. Wydaje się, że najpopularniejszym z pretendentów jest Quarkus, o którym w zasadzie wszyscy wypowiadają się w samych superlatywach. Można się zastanowić, co takiego się zmieniło, że niezagrożona do tej pory pozycja Springa nie jest już taka oczywista – i jeżeli dobrze się przyglądnąć, to dość jasnym staje się fakt, że podziękować możemy za to trzem siłom – chmurze (aczkolwiek ta sama w sobie, co najwyżej wypromowała Spring Boota), Kubernetesowi oraz GraalVM. Jeżeli spojrzeć na to, czym chwalą się w zasadzie wszystkie nowe rozwiązania, to właśnie bycie Cloud Native – co w rozumieniu javowym sprowadza się do dwóch czynników. Pierwszym z nich jest szybki start – bolączka Springa – który w znacznym stopniu ułatwia autoskalowanie w ramach klastra. Nie można też umniejszać roli faktu, że graalowe binarki są naprawdę małe, a jeżeli dobrze znamy nasze środowisko uruchomieniowe – maszyna wirtualna (poza jednak diablo szybkim kompilatorem JIT, którego jednak rozwiązania graalowe powoli gonią) nie stanowi już takiej zalety. Spring się odgryza prezentując wersję Native, a informacje o jego śmierci są srogo przesadzone, jednak na pewno twórcy tego króla JVMa muszą bacznie obserwować poczynania konkurencji.
Ok, po przeczytaniu poprzedniego akapitu z pewnością (biorąc pod uwagę mój dar przekonywania ) postanowiliście pobawić się którymś z nowych rozwiązań. Jak jednak wybrać, które z nich lepiej dopasuje się do naszego projektu? Mimo wielu podobieństw między Micronautem, a Quarkusem istnieje spora liczba różnic. Dlatego też należy podziękować SoftwareMill za bardzo interesującą analizę porównawczą obu rozwiązań. Tekst został napisany już w styczniu, ale dopiero w ostatnich tygodniach został on “zauważony” przez szeroko rozumiane “internety”, w tym do naszych łapek. Na szczęście, chociaż ostatnimi czasami Java pędzi do przodu niesamowicie szybko, tekst nie zdążył się zestarzeć ani o jotę i dalej stanowi świetne wprowadzenie do tematu.
Źródła
Odkryj więcej treści IT dopasowanych do Ciebie
W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!
Zainstaluj teraz i czytaj tylko dobre teksty!
2. Pra-JPMS – OSGI – trafia pod skrzydła fundacji Eclipse
Drugie z dzisiejszych ogłoszeń dotyczy tematu, który nie sądziłem, że kiedykolwiek jeszcze trafi do naszego małego, cotygodniowego przeglądu. Potraktujcie więc poniższe jako ciekawostkę głównie natury historycznej.
Ostatnimi tygodniami bardzo głośnym w ekosystemie wydarzeniem było przejście AdoptOpenJDK pod skrzydła Fundacji Eclipse, gdzie pod brandem Adoptium powstała grupa robocza tego projektu. Totalnie umknęło naszej uwadze, że na bardzo podobny ruch zdecydował się OSGI, który wraz z końcem poprzedniego roku rozpoczął transformację, która uczyni projekt częścią rodziny Eclipse. Końcem marca zaś ogłoszone zostało powstanie związanej z projektem Working Group.
Tych którzy nie wiedzą, czym OSGI jest, ciężko za to winić. OSGI to akronim od Open Service Gateway Initiative – specyfikacji definiującej system komponentów oparty na języku Java, czyli pierwszego podejścia do tematu modularyzacji języka, pochodzącego jeszcze z 1999 roku. Jednym z przykładów jego użycia jest m.in. system pluginów Eclipse (stąd też nie dziwi fakt przejęcia przez niego kontroli nad projektem). Przez lata była to technologia dość niszowa, aczkolwiek spotykana w niektórych większych projektach – i tylko nich. Publikacja JPMS wraz z dziewiątą wersją tego języka ostatecznie przekreśliła wszelkie szanse OSGI na masową adopcje.
Sam osobiście miałem przyjemność pracować z OSGI wyłącznie raz – było to podczas implementacji autorskiego pluginu do Confluence. Doświadczenie było dość paskudne, w związku z czym mam nadzieje, że całość relatywnie szybko odejdzie na zasłużony odpoczynek obok Appletów i Corby – aczkolwiek biorąc pod uwagę, ile legacy jest na świecie, jestem raczej pewien, że jeszcze zdarzy nam się kiedyś zmierzyć.
Źródła
- Eclipse Adoptium Welcomes You
- OSGi Core Release 8 is now final and published
- Update on the OSGi Working Group
Odkryj więcej treści IT dopasowanych do Ciebie
W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!
Zainstaluj teraz i czytaj tylko dobre teksty!
3. sun.misc.Unsafe odchodzi w niebyt wraz z Javą 17
A na zakończenie dzisiejszej edycji – kontynuacja tematu modularyzacji,
Przyznam, że mimo iż przez lata blog Oracle nie kojarzył mi się z najlepszymi materiałami “edukacyjnymi”, od kilku edycji JDK mamy do czynienia z pewną zmianą mentalu. W Oracle zauważyli chyba, że mają dość unikalną pozycję i zaczęli inwestować więcej w produkowane materiały. Mamy Podcast, Videocast, a także sporo ciekawych publikacji w ramach Java Magazine (ichniejszego bloga) – nie tylko skupiających się na istniejących funkcjonalnościach, ale
też niejednokrotnie zapowiadających przyszłe rozwinięcia platformy. Tak jest i w tym przypadku – artykuł którym się z Wami dzielimy jest bardzo istotnym studium kompromisów, na jakie musiano się zdecydować podczas wdrażania do JDK modularyzacji, równocześnie zahaczającym o Jave 17 i zmiany, jakie ma przynieść pod tym względem to wydanie.
Jak pewnie wiecie, o ile modularyzacja w ramach samych aplikacji jest problemem nietrywialnym, w dalszym ciągu pozostaje o rząd wielkości prostsza od próby wdrożenia twardej, prawie że “fizycznej” izolacji w internalach samego języka. Od pierwszych prób wdrożenia Jigsawa (nazwa kodowa JPMSa) to właśnie ten problem spędzał sen z powiek architektom.
Przykładowo, bardzo wiele aplikacji (jak i bibliotek) chcąc uzyskać maksymalny poziom wydajności, omijało zarządzanie pamięcią ze strony maszyny wirtualnej. Czynione to było poprzez używanie w teorii niedostępnych, ale istniejących na classpath-ie klas typu sun.misc.Unsafe. Wprowadzenie pełnej modularyzacji “bebechów” języka niechybnie doprowadziłoby do złamania kompatybilności wstecznej, co sprawiłoby, że masa projektów nie miałaby realnej szansy na migrację do nowej wersji Javy. W związku z tym zdecydowano się odsunąć problem w czasie – jądro języka nie zostało w pełni zmodularyzowane (wciąż można było w nim grzebać), a użycie “zabronionych” klas wiązało się z ostrzeżeniem podczas kompilacji.
Java 16 zmieniła to zachowanie – teraz powoduje ono błąd, a żeby naprawić budowanie niezbędne jest podanie prawidłowej flagi maszynie wirtualnej. Java 17 nie pozwoli nawet na to. Twórcy języka zdecydowali, że od tej pory klasy typu sun.misc.Unsafe trafią do modułu jdk.unsupported, widocznego w drodze wyjątku na classpath. Całość odbędzie się w ramach JEP 403: Strongly encapsulate JDK internals (dawno nie było JEPów, prawda )? Długoterminowym rozwiązaniem mają zaś być nowości dostarczane przez projekt Panama, które mają doprowadzić do sytuacji, gdy sun.misc.Unsafe nie będzie do niczego potrzebny.
Czego zarówno nam wszystkim, jak i twórcom JDK życzymy. W międzyczasie, jeśli chcecie poznać szczegóły całego procesu, zapraszam do wspomnianej publikacji na blogu Oracle.
Żródła
Odkryj więcej świetnych treści!
- Rozsądna ilość treści
- Tylko wysoka jakość
- Pełne dopasowanie do Twoich potrzeb!
