Społeczność Javy szuka szczęścia poza Twitterem. Chcesz dołączyć? - JVM Weekly #113

1. Usuwanie Długu Technicznego z JDK trwa w najlepsze

Zacznijmy od pakietu obowiązkowego, czyli zbioru nowości w kontekście zbliżającej się premiery (czy raczej finalnej listy funkcjonalności) do JDK 20. Tym razem nie ma tego aż tak wiele, skupimy się więc raczej na tak zwanych „Quality Outreach Heads-Ups”, które na ludzie można przetłumaczyć jako czyszczenie długu technicznego przez programistów JDK. O zapowiedzianym jeszcze we wrześniu wyrzuceniu możliwości kompilacji do bajt kodu zgodnego z JDK 1.7 już kiedyś wspominałem, teraz pora przyglądnąć się pozostałym, czeka nas bowiem trochę niespodzianek.

Pewnie kojarzycie, że w Javie klasa Thread posiada sporo metod pomocniczych – i mam nadzieje, że nie musieliście ich używać. Ciągle pamiętam, jak uczyłem się Javy z klasycznego Thinking in Java autorstwa Bruce Eckela, który na długie lata wystraszył mnie przed myśleniem o jakiejkolwiek asynchroniczności w Javie. Thread.wait(), Thread.join() i Thread.notify(), służące do niskopoziomowego zarządzania współbieżnością zawsze wydawało mi się bardzo koślawe i bardzo cieszę się, że w JDK 1.5 dodane zostało java.util.concurrent. Klarowności API dostarczanego przez Thread nie pomagało jednak to, że klasa udostępniała także dodatkowe metody – Thread.stop(), Thread.suspend(), Thread.resume(), które jak się okazuje, były zdeprecatowane już od JDK 1.2. Teraz nareszcie przyszedł czas, aby się ich pozbyć. Zgodnie z zapowiedziami, nastąpi to właśnie w JDK 20. Więcej szczegółów znajdziecie w dokumencie Java Thread Primitive Deprecation

To tylko pokazuje, jak bardzo na sercu twórcy Javy mają wsteczną kompatybilność

Ostatnią z usuwanych funkcjonalności jest wyczyszczenie niepotrzebnego już Multithreaded Custom Class Loaders. Był to swoisty woraround – etap pośredni, który niezbędny był do zmigrowania niektórych aplikacji do nowej architektury Class Loaderów, wprowadzony jeszcze na poziomie JDK 1.7. Teraz, gdy pozbyto się resztek wersji 1.7 z platformy, przyszedł czas również na deprekacje i wyłączenie wspomnianych Class Loaderów.

Może do czasu JDK 30 pozbędziemy się ich z projektu.

Co oprócz tego? Nowe JEPy powiązane z Projektem Loom. Zanim jednak poniesie Was za bardzo wyobraźnia, drugie preview Wirtualnych Wątków oraz druga inkubacja Structure Concurrency nie niosą za sobą jakichś szczególnie dużych zmian. Po prostu kilka zmian API, które zostały jakby bokiem przepchnięte w ramach poprzedniej iteracji proposali (jak np. ExecutorService rozszerzający interfejs AutoCloseable) zostały ustabilizowane i wmigrowane do stabilnego codebase JDK, przez co naturalnym było ich zniknięcie z JEP-a. Na JEPy przeniesiono również zmiany związane z wątkami, o których pisałem w poprzednich akapitach. Poza tym pracę nad oboma proposalami nie posunęły się do przodu w obserwowalny z zewnątrz sposób.

A jeżeli jesteście zawiedzeni zmianami w Loomie, to chciałem zakomunikować, że ze snu zimowego (czy raczej jesienno-letniego) wybudził się ostatnio Project Valhalla i mam nadzieje, że niedługo doczekamy się większych ogłoszeń. Ale po takim rozgrzaniu Waszych apetytów zostawię to sobie na inną okazję.

Żródła

2. foojay.io tworzy serwer Mastodon dla Java Developerów

Nie chciałbym się za dużo rozpisywać o tym, co dzieje się w Twitterze – po pierwsze, od tego mam sobotnie przeglądy Software Craftsmanship Weekly (do których lektury zachęcam), z drugiej chyba wszyscy mamy tej dramy trochę dość. Wspominam o niej jednak dlatego, że sprawa przeszczepiła się na świat javowy w dość ciekawy sposób.

Otóż – przynajmniej na poziomie komunikacji – jesteśmy świadkami wielkiego odwrotu od Twittera. W zasadzie cały świat technologiczny zaczął rozglądać się za alternatywą dla platformy Elona Muska. Jednym z głównych kontenderów do tronu wydaje się być Mastodon. Jeżeli uznamy – jak kazałby nam przekaz medialny – Twittera jako prywatny folwark jednej osoby, Mastodon jest platformą federacyjną. Oznacza to, że nie ma w niej żadnego głównego feedu (choć na taki pozycjonuje się mastodon.social), a doświadczenie użytkownika budowane jest przez wiele różnych społeczności, do których może dołączyć. W tym tygodniu foojay.io, jeden z największych (i najlepszych) portali poruszających tematy związane z JDK. W błyskawicznym tempie (od propozycji do uruchomienia minęło niecałe 48h) stworzyli oni własne Community foojay.social, na które zapraszają użytkowników. Ja również zapraszam, sam zamierzam się tam tonę poudzielać.

Będąc adwokatem diabła – Ben Thompson (autor Stratechery) twierdzi, że bardzo trudno jest zreplikować główną wartość Twittera, który jest wielki „equalizatorem” umożliwiającym dyskurs z największymi tego świata. A to dość kiepsko spina się z modelem federacyjnym.

Jeśli chcecie dowiedzieć się więcej, czym jest Mastodon – ostatnio tekst w tym temacie napisał sam Martin Fowler. Warto też w tym temacie wspomnieć, że również Twitter od pewnego czasu pozwala na tworzenie grup dyskusyjnych skupionych w koło pojedynczego tematu. Przykładowo, tutaj możecie znaleźć javową, która należy do jako tako aktywnych – choć mam wrażenie, że raczej używana jest głównie do promocji własnych materiałów dotyczących języka przez autorów (guilty as charged). Całość może jednak dać Wam przedsmak tego, jak wyglądać może taki stricte tematyczny feed.

Ostatnią rzeczą, o której chciałem wspomnieć jest Java Bubble – jest to utrzymywana przez społeczność (a dokładnie przez Marc R. Hoffmanna) lista osób, które dzielą się swoją wiedzą dotyczącą Javy. Jeśli zastanawialiście się, kogo warto śledzić w ekosystemie – myślę, że jest to dobry punkt startowy.

Źródła

3. Usługa Serverless dla Jakarte EE – Serio

Nikt:
Dalej Nikt:
Payara: Zróbmy Cloud Serverless dla Jakarta EE!

Przyznam, że dawno żaden nagłówek mnie tak nie zaskoczył jak informacja o tym, że Payara postanowiła stworzyć Payara Cloud – Platform-as-a-Service dla aplikacji napisanych w Jakrata EE. Działa to tak, że bierzesz swojego *.war zgodnego ze specyfikacją Jakarta Web Profile, uploadujesz go na chmurę i… gotowe. W pierwszej chwili jedyne, co mi się pojawiło w głowie to „czego to ludzie nie wymyślą” i prawie zacząłem scrollować dalej… ale jednak nagle „klikło” i z perspektywy stwierdzam, że ma to właściwie sporo sensu i dobrze wpisuje się w historie platformy jaką jest Jakarta EE.

Bo powiedzmy sobie szczerze – standard Java EE powstał w końcu po to, aby być w stanie odseparować języka od konkretnej implementacji dostarczonej przez poszczególnych vendorów. Tego typu podejście idealnie więc wpisuje się w sytuację, w której dostawcy infrastruktury są w stanie zapewnić dedykowane pod Jakartowe API. Ja wiem, dzisiaj i tak to pakujemy wszystko w Dockery, ale tak naprawdę stanowią one dodatkową warstwę nad taką czystą, skalowalną platformą Serverless, jaką obiecuje nam Payara. Jeśli dodatkowo spojrzymy na Serwery Aplikacyjne jako środowisko uruchomieniowy dla aplikacji (czym w zasadzie są), to podejście „wrzucam jar/war i zapominam o mojej aplikacji cloud-native” wydaje się być aż nazbyt kuszące. Po prostu ponownie historia zatoczyła koło.

Zresztą, to nie jest pierwszy projekt „ucloudnatywiający” aplikacje Jakarta EE. Jest jeszcze Pirania Cloud, którego celem jest konteneryzacja aplikacji napisanych zgodnie z zasadami Jakarcie EE. Tego typu paczuszkę możemy po prostu wrzucić na dowolną chmurę. Stwierdziłem, że warto o tym wspomnieć przy okazji jej najnowszego wydania 22.11, które ukazało się w zeszłym tygodniu.

Źródła

4. Quarkus zapowiada swoją „trzecią” edycję z masą interesujących zmian

No i na sam koniec mamy chyba największe ogłoszenie zeszłego tygodnia, czyli przymiarki do trzeciej wersji Quarkusa. Podbicie „dużej wersji” zawsze pozwala twórcom na zrobienie dużego skoku do przodu, a patrząc po ilości zmian, które są planowane w nowym Quarkusie, to jego twórcy skwapliwie z tej opcji skorzystali.

Co ciekawe, zmiany wychodzą poza standardowe podbicie wersji API, bibliotek i platform, choć tych też nie brakuje. Nowy Quarkus przyniesie bowiem Hibernate 6, Jakarte EE 10 (co – pamiętajcie – rozwala kompatybilność) oraz MicroProfile 6 (na którego premierę zresztą ciągle czekamy, ale o jego temat akurat zahaczaliśmy w zeszłym tygodniu). Pod maską jednak znajdziemy sporo znacznie ciekawszych rzeczy.

Nowy Quarkus przynosi min. wsparcie dla HTTP/3, które możecie znać również pod nazwą Quic. Protokół ten można w uproszeniu określić jako implementacje standardowego modelu request-response znanego z HTTP, ale opartą zamiast na TCP to UDP. Dzięki temu zapewniać ma znacznie lepszą wydajność w wypadku aplikacji webowych, które pobierają znaczne ilości zasobów zewnętrznych. W tym miejscu zakończę, ale jeśli jesteście ciekawi większej ilości detali – tutaj znajdziecie bardzo dobre, 5-minutowe wprowadzenie, a post QUIC Is Not a TCP Replacement to świetny materiał wchodzący w niuanse i filozofię stojącą za nowym protokołem.

Jak to mówili w szkole – „dla ambitnych”.

Kolejną nowością, do której zrozumienia przydadzą się materiały zewnętrzne jest wsparcie io_uring. io_uring to nowe (i tak realnie nowe – trafiło do kernela w 2019 roku) asynchroniczne API I/O dla Linuksa stworzone przez Jensa Axboe z Facebooka. Przyznam, że jestem zaintrygowany tym, jak twórcy Quarkusa chcą całości użyć i dogrzebałem się, że prawdopodobnie zmodyfikowany zostanie główny Event Loop Quarkusa. Aczkolwiek jeśli ktoś z zespołu Quarkusowego to przypadkiem czyta: dajcie znać w komentarzu – jestem zaintrygowany.

Oczywiście, nowa wersja Frameworki musi uwzględniać ostatnie zmiany w JDK, w związku z tym na liście nowości nie mogło zabraknąć również Projektu Loom – wirtualnych wątków i Strukturalnej Współbieżności. Tego się wszyscy spodziewaliśmy, ale to co przykuło moje oczy to chęć porzucenia Reactive Streams na rzecz jego implementacji pochodzącej z JDK 9 – java.util.concurrent.Flow. Jako, że Reactive Streams to standard, który Flow implementuje (Quarkus zresztą używa alternatywy o nazwie Mutiny), zastanawiam się, czy jest to jakiś skrót myślowy na porzucenie wspomnianego Mutiny czy jeszcze coś innego chodzi po głowie twórcom.

Ponownie – serdeczna prośba tu o wyjaśnienia 🙏

Ostatnią ciekawostką, na którą natknąłem się w zapowiedzi jest obietnica „rmfactoru” dokumentacji na nowy format. Przy okazji dowiedziałem się bowiem o istnieniu frameworka (koncepcyjnego, nie, że jakiejś biblioteki) do tworzenia dokumentacji użytkownika o nazwie Diátaxis. Liczba projektów, które go zaadoptowały jest całkiem pokaźna, a że niedługo dołączy do niej również do niego Quarkus, jest to chyba najwyższy czas, żeby się zainteresować co ciekawego wprowadza on do już istniejącego szeregu dobrych praktyk.

To oczywiście nie wszystko, ponieważ twórcy, zgodnie z naturą frameworku RedHata, obiecują nam również lepszą wydajność i polepszony „developer experience” Co ciekawe, całości możemy spodziewać się już całkiem niedługo, bo wersja finalna planowana jest na luty. Możecie być pewni, że przy okazji pierwszych wersji Alfą do tematu wrócę

Społeczność Javy szuka szczęścia poza Twitterem. Chcesz dołączyć? – JVM Weekly #113

1. Usuwanie Długu Technicznego z JDK trwa w najlepsze

Żródła

2. foojay.io tworzy serwer Mastodon dla Java Developerów

Źródła

3. Usługa Serverless dla Jakarte EE – Serio

Źródła

4. Quarkus zapowiada swoją „trzecią” edycję z masą interesujących zmian

Źródła

Odkryj więcej świetnych treści!