W dzisiejszej edycji opada już kurz po bitwie (czy raczej premierze Javy 17) i możemy zacząć patrzeć w przyszłość – a ta rysuje się bardzo interesująco. Zapraszamy do nowej edycji!
1. Zbliża się premiera Project Loom 🕰
Ostatnie tygodnie były głównie opisem tego, co wyszło w Javie 17. Nie powinniśmy jednak żyć przeszłością – to, że mamy za sobą dużą premierę, wcale nie oznacza, że świat stanął w miejscu. Wręcz przeciwnie. Przez listy mailingowe Javy znowu zaczęły przewijać się plany przyszłych wydań – zarówno JDK 18, jak i późniejszych.
Pewnie ciężko w to uwierzyć, ale wszystkie znaki wskazują, że Project Loom powoli zmierza ku końcowi. Niech świadczy o tym fakt, że twórcy są na tyle pewni stabilności obecnej wersji swojego rozwiązania, że poszukują aktualnie chętnych do przepisania go na inne architektury procesorów niż x86_64. Ponad cztery tysiące linii związane są właśnie z tą konkretną architekturą, i to one właśnie wymagają przepisania. Przy okazji próby znalezienia chętnych do wsparcia projektu w tym zakresie, Alan Bateman zdradził, że już niedługo możemy spodziewać się pierwszych JEPów związanych bezpośrednio z projektem.
Jednak Loom nie jest jedynym projektem, nad którego portowaniem przewinęły się ostatnio dyskusje. Felix Yangfei z Huawei zaproponował stworzenie edycji Javy… na platformę RISC-V. Pogrzebałem trochę, i okazało się, że jest to alternatywa dla ARM, którą mocno interesują się chińczycy. Czytelnicy naszych sobót pewnie zdają sobie sprawę, że Chiny-USA są obecnie na poziomie relacji, która określana jest czasem jako Nowa Zimna Wojna. W tej wojnie amunicją jest właśnie m.in. standard ARM. Patrząc z tej perspektywy propozycja Felixa nabiera drugiego dna.
Na koniec – żeby nie było tak że nic o Javie 17 dzisiaj nie ma – Adoptium (dawne AdoptOpenJDK) podzieliło się swoją własną, w pełni otwartą edycją Javy 17, która dla przypomnienia nosi uroczą nazwę Temurin. Zapraszamy do pobierania.
Źródło
Zainstaluj teraz i czytaj tylko dobre teksty!
2. Kolejne dane na temat użycia Jakarty EE 📗
Jakarta EE dość regularnie jest badana. Podejrzewam, że jej twórcy wolą trzymać rękę na pulsie i sprawdzać stan społeczności – mimo, że ostatnimi czasy odzyskuje nieco respektu wśród programistów (a przynajmniej tak się dzieje w mojej bańce), to jednak jej pozycja jest dość chwiejna. Dlatego przyglądnijmy się – co też ciekawego znajdziemy w opracowaniu Jakarta EE Survey?
Raport uwidacznia nam duopol, w jakim aktualnie znalazł się ekosystem. W świecie zdominowanym przez Springa (posiadającym 60% zasięgu), Jakarta EE jawi się jako używana przez prawie 50% – platforma chwali się 12% wzrostem. Microprofilu używa zaś aż 34% – ankieta nie rozbija tego niestety na konkretne implementacje. Ogólnie w całym raporcie nie znajdziemy za wiele ani Helidona, ani Quarkusa. Ten pierwszy nie pojawia się w niej wcale, ten drugi jest wspomniany wyłącznie jako trzeci najpopularniejszy runtime.
Z ciekawych informacji warto też wspomnieć, że ponad 75% użytkowników chwali się, że używa wersji Javy/Jakarty EE 8 i więcej. Łącząc to z faktem, że 43% respondentów używa Jakarty do tworzenia Mikroserwisów (w kontraście do 18% monolitu), dość elegancko wyłania się nam demografia badania. Podejrzewam, że Eclipse Foundation dotarło raczej do ludzi będących bardziej na bieżąco z nowymi wersjami, nie tych utrzymujących stare, enterprisowe legacy. Może być to nieco zakrzywiona perspektywa (aczkolwiek każde badania Jakarty przez Jakartę będą takowymi), ale przynajmniej możemy zobaczyć, jak wyglądają odczucia najbardziej aktywnej części społeczności.
Na koniec warto spojrzeć na ulepszenie, w jakim zakresie najbardziej liczy społeczność. Są to:
- Natywne wsparcie dla Kubernetesa
- Lepsze wsparcie w budowie mikroserwisów
- Szybsze tempo innowacji
Źródła
Zainstaluj teraz i czytaj tylko dobre teksty!
3. kotlinx.serialization 1.3… i pierwszy milestone Kotlin 1.6 🥫
A na koniec drobiazgi związane z Kotlinem. Ale interesujące drobiazgi.
Ukazała się nowa edycja jednego z najważniejszych rozszerzeń Kotlina: kotlinx.serialization 1.3. Posiada ona kilka ważnych zmian. Po pierwsze, nareszcie możliwe będzie parsowanie JSONa bezpośrednio z Input Streama i innych struktur javowego IO. Nareszcie też możliwe będzie wyrzucenie wartości “nullowych”. Bardzo się z tego cieszę, bo brak tej możliwości wymusił kiedyś ode mnie bardzo paskudne “haki” z użyciem polimorfizmu. A skoro już o nim – również obsługa hierarchii klas ma być teraz bardziej elegancka. Twórcy oddali programistom większą kontrolę nad enkoderami.
Dodatkowo, informujemy też o pierwszym milestonie Kotlina 1.6. Oprócz zmian już testowanych w wydaniach pośrednich 1.5, zawiera ponad 100 nowych JEPów. Będziemy informować o rozwoju nowej edycji Kotlina.