Duże zmiany w leadershipie Kotlina: Roman Elizarov odchodzi z JetBrains – JVM Weekly vol. 152

1. Wywiad z Brianem Goetzem na temat przeszłości, teraźniejszości i przyszłości Javy

Wywiady należą do moich najbardziej ulubionych rodzajów materiałów, które na szczęście dzięki popularności podcastów są obecnie bardziej powszechne niż kiedykolwiek wcześniej. Umożliwiają one autentyczne spotkanie różnych perspektyw, nawet gdy prowadzący służy głównie jako „proxy” dla wątpliwości słuchaczy. Te interakcje (zwłaszcza jak wywiad jest dobrze prowadzony) utrudniają ukrycie słabszych stron omawianych koncepcji czy rozwiązań – szczególnie w porównaniu z tekstami pisanymi, które zazwyczaj są filtrowane przez pryzmat jednego twórcy i bardzo łatwo uciec w nich od niewygodnych pytań… no bo wiecie, nie ma pytań.

Dlatego dzisiaj chciałem rozpocząć od wywiadu z Brianem Goetzem z oficjalnego kanału Java, w który zagłębia się w różne aspekty języka, racjonalizując niektóre decyzje. Rozpoczyna od omówienia konwencji nazywania getterów i setterów w rekordach Java, sugerując odejście od przestarzałej konwencji Java Bean. W miarę rozwoju rozmowy Goetz omawia zalety niemutowalności, podkreślając pułapki związane z nadmiernym poleganiem na mutacji stanu. Dyskusje obejmują również potencjał typów Union w Javie, wyzwania, jakie mogą wprowadzić, oraz delikatną równowagę między włączaniem wyjątków do API Stream.

W drugiej części wywiadu Goetz bada zaawansowane koncepcje Javy i nadchodzące funkcje. Omawia tam potencjał na automatyzację opakowywania i delegowania metod, sugerując, że jest to rozważane dla przyszłych wersji Javy. Ważną częścią wywiadu jest też delikatny balans między ryzykiem, a zyskiem płynącym z nowych funkcji Preview, gdzie Goetz podpiera się trwającym Projekt Valhalla. Kończąc wywiad, Goetz omawia perspektywy na wdrożenie natywnej struktury tabeli danych w Javie, co pozwoliłoby wejść na rejony mocno zarezerwowane dla rozwiązań pokroju pythonowych Pandas i NumPy, i wyrażając optymizm co do przyszłego znaczenia Javy w rozwoju gier i edukacji.

Jak widzicie, masa mięska. Bardzo polecam zapoznać się z unikalną perspektywą człowieka, który stoi za rozwojem sporego kawałka Javy:

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!

2. Roman Elizarov odchodzi z JetBrains i kończy swoją pracę nad Kotlinem

W świecie Kotlina piątkowym popołudniem gruchnęła Roman Elizarov, lead projektu, ogłosił swoje odejście z JetBrains z powodów osobistych, kończąc w ten sposób również swoją pracę nad językiem. Pożegnanie odbyło się serią tweetów, w których wyrażając wdzięczność za możliwość pracy nad Kotlinem i podkreślając swoje wielkie uznanie dla społeczności Kotlina.

Dowiedzieliśmy się też kto w przyszłości stanie za sterami języka – Mikhail Zarechenskiy, wcześniej pracujący za kulisami w JetBrains, zostanie głównym projektantem Kotlina. Kluczowe zmiany w zespole obejmują też Hadi Hariri, którego możecie znać jako Co-hosta podcastu Talking Kotlin – przejmie on teraz więcej obowiązków poza działaniami promocyjnymi i jego zaangażowaniem w KotlinConf. Również drugi prowadzący Talking Kotlin, Sebastian Aigner, będzie odgrywać teraz ważniejszą rolę w Kotlin Foundation, szczególnie w wsparciu inicjatyw szerszego ekosystemu Kotlin. Egor Tolstoy dalej zaś będzie kierować zespołem od strony Product Managementu .

Prywata: w tym miejscu chciałbym wyrazić moją szczery wdzięczność za wpływ, jaki Roman Elizarov miał na moją drogę zawodową. To jego publikacje sprawiły, że wciągnął mnie świat JVM Runtime i projektowania języków programowania – w naciągany sposób jest więc to osoba, która jest w związku z tym „ojcem chrzestnym” tego newslettera.

3. Release Radar

Helidon 4.0

Helidon 4 został oficjalnie wydany, stając się pierwszym na świecie frameworkiem do mikroserwisów opartym o wirtualne wątki. Główną zmianą przychodzącą z wydaniem jest więc oczywiście zastąpienie Netty nową implementacją serwera o nazwie Níma. Níma został zaprojektowany tak, aby w pełni wykorzystywać wirtualne wątki Java 21, umożliwiając każdemu requestowi działanie na dedykowanym wirtualnym wątku. Upraszcza to proces wykonywania blokujących operacji i zapewnia wysoki poziom współbieżności, eliminując w ten sposób potrzebę skomplikowanego kodu asynchronicznego, co zwiększa wydajność, zwłaszcza (według doniesień samych twórców) w Helidon MP. Oznacza to również, że doczekaliśmy się pierwszego framework wymagającego do działania Java 21… wydanej zaledwie miesiąc temu.

Helidon SE, stanowiący podstawowy zestaw API dla Helidon, również przeszedł sporą transformację. Adopcja wirtualnych wątków umożliwiła przejście od asynchronicznych API do blokujących (aż się sam dziwie pisząc to zdanie). Ta zmiana upraszcza kod, czyniąc go łatwiejszym w pisaniu, utrzymaniu i zrozumieniu – daje nam to przedsmak tego, co czeka pewnie w przyszłości cały ekosystem. Osoby korzystające z Helidon 3 SE będą musiały niestety znacznie dostosować swój kod do zaktualizowanych API. Chociaż może to wymagać pewnego początkowego wysiłku, korzyści w postaci zwiększonej wydajności i prostoty kodu wydają się tego warte. Oficjalny przewodnik aktualizacji dostarcza wskazówek dotyczących migracji aplikacji do odnowionego Helidon 4 SE.

Najnowsza wersja Helidon obsługuje również MicroProfile 6.0. Ponadto wydanie towarzyszy oficjalny przewodnik aktualizacji dedykowany dla Helidon 4 MP, pomagający użytkownikom w nawigacji po zmianach i zapewniający płynne przejście.

Całość to świeżynka (news miał miejsce dopiero wczoraj), której pewnie jeszcze w przyszłości poświęcimy miejsce – po ocenie jak nowe podejście sprawdzi się w akcji.

A jak już dotknęliśmy tematu Microprofile…

Microprofile 6.1

MicroProfile z zaprezentowała wydanie MicroProfile 6.1. Zaktualizowana wersja w pełni integruje się z Jakarta EE 10 Core Profile. Wydanie samo w sobie nie wprowadziło żadnych nowych API, za to pojawiły drobne ulepszenia w konfiguracji MicroProfile, metrykach i telemetrii. Poniższa grafika pokazuje pełną listę zmian.

MicroProfile 6.1 wymaga Java SE 11, a jeżeli ktoś chciałby go spróbować już dziś – Open Liberty 23.0.0.10-beta jest pierwszą zgodną implementacją. No cóż, dla odważnych.

Oficjalne rozszerzenie Javy dla Visual Studio Code od Oracle

Oracle opublikowało oficjalne rozszerzenia Javy dla Visual Studio Code, co można uznać za zauważenie rosnącej popularności Visual Studio Code jako alternatywy dla klasycznych IDE. Mimo że Java posiada specjalizowane IDE (jak choćby Intellij), znaczna liczba programistów Java, w tym choćby studenci i ci, dla których jest to nie-wiodący język, preferuje dzisiaj VS Code. Żeby daleko nie szukać – u mnie też stanowi formę scyzoryka szwajcarskiego.

Pierwsza wersja zawiera funkcje takie jak auto-uzupełnianie, podświetlanie błędów, wsparcie dla debugowania oraz kompatybilność z projektami Gradle i Maven. Jeszcze ciekawsze rzeczy dzieją się jednak pod maską. Podstawą tego rozszerzenia do VS Code jest bowiem serwer języka, który komunikuje się z IDE za pomocą protokołu Language Server Protocol. Serwer języka Java od Oracle’a bazuje na tym używanym w projekcie Apache Netbeans i wykorzystuje kompilator javac z OpenJDK JDK. Gwarantuje to szybkie wsparcie dla nowych funkcji JDK w VS Code. Co więcej, podczas gdy rozwój serwera języka będzie kontynuowany w ramach projektu Apache NetBeans, rozszerzenie do VS Code będzie częścią odrębnego projektu open source.

Dla tych, którzy nie wiedzą, protokół Language Server Protocol (LSP) to standaryzowany protokół komunikacji między narzędziami programistycznymi (takimi jak środowiska programistyczne lub IDE) a serwerami języka, które dostarczają funkcjonalności specyficzne dla danego języka, takie jak uzupełnianie kodu, sprawdzanie błędów i refaktoryzacja. Dzięki LSP narzędzia mogą obsługiwać wiele języków programowania, nie implementując funkcji specyficznych dla danego języka, a pojedynczy serwer języka można wykorzystać w wielu narzędziach. Jest to więc spora szansa dla nowych IDE, które nie muszą całego wsparcia tworzyć od zera.

PS: Temat jest mi bliski, bo w mojej firmie – VirtusLab – rozwijamy serwer języka dla Scali – Metals.

WildFly 30

Swoją premierę miał też okrągły WildFly 30. Mimo że oficjalna rekomendacja to nadal JDK 17 lub 11, znacząca część tego wydania została poświęcona integracji z Java SE 21. Najnowsza wersja przechodzi na tej wersji testy certyfikacyjne zarówno Jakarta EE 10 Core Profile, jak i Microprofile. Wraz z coraz większym naciskiem na JDK 21 przewiduje się, że WildFly 30 może być ostatnim, które wspiera JDK 11.

Dodatkowo, wraz z przyjściem WildFly 30 nastąpiła zmiana licencji z Lesser General Public License 2.1 na Apache Software License 2.0, podsumowując w ten sposób długoletnią ścieżkę. Przejście z Lesser General Public License 2.1 (LGPL 2.1) na Apache Software License 2.0 (ASL 2.0) oznacza przejście z licencji „słabej” copyleft na bardziej liberalną. Podczas gdy LGPL 2.1 pozwala na łączenie z oprogramowaniem własnościowym, ale wymaga, aby modyfikacje licencjonowanego oprogramowania były wydawane na tej samej licencji LGPL 2.1, ASL 2.0 pozwala użytkownikom swobodnie używać, modyfikować i dystrybuować oprogramowanie, w tym włączanie go do projektów własnościowych, bez obowiązku ujawniania modyfikacji czy pochodnych prac. Ważne jest jednak, aby zaznaczyć, że WildFly korzysta z wielu bibliotek komponentów na różnych licencjach open-source, a zmiana licencji dotyczy tylko części z nich.

Eclipse Temurin JDK 21

To już tak bardziej w formie wzmianki – nareszcie doczekaliśmy się wariantu JDK 21 wydawanego przez Eclipse Foundation, będącego spadkobiercą starego AdoptOpenJDK. Podejrzewam, że sporo osób na niego czekało.

Ciekawe są kulisy ponad miesięcznego opóźnienia w stosunku do pozostałych wersji. Mimo przeprowadzenia testów i weryfikacji kodu źródłowego OpenJDK 21 GA, oficjalne wydanie Temurin 21 napotkało na opóźnienia spowodowane nową umową licencyjną dotyczącą testów Java 21 TCK, która została wprowadzona krótko przed GA OpenJDK 21. W związku z tym Fundacja Eclipse musiała dokładnie ocenić i zaakceptować tę aktualizowaną umowę. Przez pewien czas dostępne były jedynie wersje wczesnego dostępu, które nie były zalecane do użytku produkcyjnego. Jednak do 9 października 2023 roku Adoptium otrzymało Java Technology Compatibility Kit (TCK) dla Java 21, zapewniając jej zgodność ze specyfikacją Java. Przeprowadzenie wszystkich testów TCK zajęło trochę czasu, ale finalna wersja trafiła w nasze ręce.

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!

A na koniec dwie interesujące strony

https://rss.xlit.app/updates – Ostatnimi czasy wpadłem na konto Twitterowe (i towarzyszący mu RSS), które pozwalają na śledzenie nowo pojawiających się JEP-ów, całość stworzona przez Alireza Ghasemi. Nic rewolucyjnego, ale jeśli chcecie mieć pewność, że nie przegapicie żadnego nowego materiału – narzędzie pozwala śledzić listę już od stanu Draft.

awesomejava.resamvi.io – kojarzycie listy Awesome, zbierające najważniejsze narzędzia dla developerów lub interesujące materiały, wszystko będąc kurowanymi przez społeczność. Ich ilość jest tak duża, że powstały już meta-listy (jak Awesome Awesome, która zbliża się do 300 000 gwiazdek na GitHubie ) czy potrzeby alternatywnych sposobów przeglądania. Takim czymś jest awesomejava.resamvi.io. Zawiera ona bowiem oficjalną (na ile oficjalna może być lista awesome) edycje Javową, ale z małym twistem – otóż każda z kategorii została posortowana pod względem wspomnianych już „gwiazdek’. Wiem, że dla wielu osób jest to istotne kryterium (i wcale nie najgorsze proxy do podejmowania decyzji), dlatego jeśli do tej pory odbijaliście się od „awesome list”, dajcie szanse tej nowej prezentacji idei.

PS: Trochę out-of-scope, ale polecam również system-design-101, nowe repozytorium materiałów od ByteByteGo. Jest naprawdę świetne, zwłaszcza jak ktoś potrzebuje powtórki przed rekrutacją, ale nie tylko 🙂

A na koniec trochę prywatnych wrażeń z ostatnich wojaży

Zarówno Geecon, jak i EclipseCon były rewelacyjnymi imprezami, które mam odwiedzić za rok. Poznałem tam nie tylko wielu fantastycznych ludzi, ale również mogłem spojrzeć na nasz ekosystem z nieco innej perspektywy. Odkryłem na przykład, że niemiecka społeczność Java, iJUG, konsekwentnie publikuje fizyczny magazyn papierowy „Java aktuell” od 2010 roku 😳.

PS3: Odkryłem też na nowo moją dawną pasję do naklejek na laptopy. Niczego nie żałuje.

Jeśli jesteście ciekawi co ciekawego działo się na EclipseCon – Ivar Grimstad, Developer Advocate Jakarty EE, podzielił się wrażeniami na swoim blogu. Niestety, nie znalazłem żadnego opracowania GeeCon Prague, a sam dotarłem tylko na drugi dzień… mój samolot opóźnił się prawie 5 godzin.

I tym wesoło-smutnym akcentem żegnam się! Do zobaczenia w następnej edycji, już mam nadzieje w regularnym trybie.