Dzisiaj trzy tematy, i właściwie każdy z nich zasłużył na nagłówek… co jednak pokazuje, jak dużo się działo w ostatnim tygodniu. Będzie więc zapowiedź Kotlina 2.0, masa eksperymentów z Projektem Loom oraz… czyżby w Javie miały się pojawić kotlinowe Nulle?
1. Nadchodzi Kotlin 2.0
Okazuje się, że w świecie Kotlina szykują się spore zmiany – przynajmniej jeśli chodzi o numeracje.
Twórcy ogłosili bowiem, że wydanie 1.9 będzie ostatnim z linii 1.x. Wersja 1.10 się nie pokaże, zamiast niej przeskoczymy od razu do wydania 2.0. Wynikać ma to z faktu, że to właśnie na tą wersje planowane jest wydanie długo oczekiwanego kompilatora K2 – „jednego, by wszystkimi rządzić” i mającego zapewnić wspólną infrastrukturę dla wszystkich potencjalnych targetów języka. Dzięki temu jego twórcy nie będą musieli każdorazowo implementować tych samych funkcjonalności na potrzeby JVM, WebAssembly czy Androida, co ma znacznie przyspieszyć ewolucje Kotlina. Zmiana jest więc na tyle duża, że uznano za zasadne odpowiednie ukoronowanie jej podbiciem numeracji.
Zmiana „dużej” wersji języka potrafiła mocno zamieszać w ekosystemie danego języka, jednak w wypadku Kotlina JetBrains obiecuje bardzo stabilny proces migracji. Ma być to możliwe do osiągnięcia dzięki dwóm składowym. Po pierwsze, zmiany motywujące podbicie numeracji odbywają się pod maską, a twórcy celowo nie planują wprowadzać w nowym wydaniu żadnych nowych nowości w samym syntaksie języka – te zostawiają sobie na wydania 2.x, które przyjdą po udanym przejściu na K2. Dodatkowo jednak JetBrains zyskuje na tym, że kontroluje zarówno Kotlina, jak i jest głównym dostawcą narzędzi do niego. Pozwala to bowiem na znacznie sprawniejsze przeprowadzenie całej operacji, gdy większość najważniejszego toolingu może być rozwijana równolegle z językiem.
Równocześnie z powyższą zapowiedzią ukazała się wersja preview wydania 1.8.20, która wprowadza flagę -language-version 2.0
. Ta umożliwia przetestowanie najnowszych zmian w kompilatorze. Jakich? Do tematu wrócimy sobie pewnie wraz z wydaniem wersji stabilnej, ale 1.8.20 będzie wydaniem mocno skupiającym się na internalach języka.
Źródła
Zainstaluj teraz i czytaj tylko dobre teksty!
2. Społeczności MicroProfile, Scali i Kotlina bawią się projektem Loom
Nazbierało się trochę ogłoszeń około-loomowych, im więc poświęcimy kolejną sekcje.
Zacznijmy od Helidon Níma, projekt bowiem opublikował w zeszłym tygodniu wersję ALPHA4. Nie zwykłem informować Was o tak wczesnych wydaniach, tym razem Alpha jest jednak naprawdę ciekawa. Twórcom Níma udało się bowiem dokonać sporego osiągnięcia, jakim jest stworzenie implementacji API MicroProfile 5.0 kompatybilnych z Wirtualnymi Wątkami, a dokładnie na implementacji WebServera dostarczanej przez Níma. Jest to olbrzymi skok dla projektu (i właściwie dla całego community w koło MP).
W ostatnim tygodniu pojawił się również tekst Prototype Loom-based concurrency API for Scala Adama Warskiego, CTO SoftwareMill, w którym ten eksperymentuje z konceptem stworzenia „natywnego” API dla wirtualnych wątków w Scali, wykorzystujące system typów języka w sposób uniemożliwiający programistom kopnięcie się w kolano. Należy bowiem pamiętać, że wirtualne wątki same w sobie to dość niskopoziomowe API, które większość programistów będzie pewnie używać jednak poprzez jakąś abstrakcję.
Tekst dotyka tematu Structured Concurrency, Scoped Values oraz dokonuje porównania eksperymentalnego API (prototyp którego Adam nazwał ox – cOncurrency eXtensions) z istniejącymi w Scali rozwiązaniami. Na tym etapie, jak łatwo się domyśleć, rozwijane od wielu lat biblioteki są o wiele dojrzalsze. Należy jednak pamiętać, że jak ma to miejsce w przypadku Reactive Extension, tak również kod monadyczny jest po prostu trudniejszy do zrozumienia dla niewprawionego w nim programisty. To, co przynosi zaś Loom, to prostota użycia, nawet jeśli jego abstrakcja nie ma jeszcze gotowych wzorców na wszystkie problemy.
Sam tekst jest jednak świetny i jeśli macie choć trochę zainteresowania językami funkcyjnymi, będzie to świetna lektura. Sam kod Ox też jest dostępny na GitHubie, więc wolący naukę przez eksperymentowanie też znają coś dla siebie.
A że było już dzisiaj o Kotlinie, to rzućmy też okiem, jak ten język przygotowuje się do zbliżającej się premiery Projektu Loom. Przyznam, że przeglądając się Roadmapie języka próżno szukać tam wirtualnych wątków, ale może wynikać to z faktu, że same korutyny są na tyle elastyczne, że umożliwiają uruchomienie na wielu Dispatcherach. Oznacza to, że łatwo można „wymienić” model asynchroniczności działający pod spodem. Tak jak więc mamy Dispatcher dla RX, tak łatwo można stworzyć taki dla Looma.
Temat przewinął się w grudniu w podcaście „Talking Kotlin” JetBrains, gdzie Urs Peter rozwija temat i pomimo złowieszczego tytułu Will Loom Kill Kotlin Coroutines? buduje narracje, że tak naprawdę to właśnie Kotlin najszybciej będzie w stanie skonsumować wartość z wirtualnych wątków. Te są bowiem funkcją niskopoziomową, a Korutyny już dzisiaj dostarczają wysokopoziomowe API, posiadające ustandaryzowane sposoby na radzenie sobie z programowaniem asynchronicznym – jest to więc ten sam temat, który przewija się przez powyższy tekst o Scali. Jeżeli jesteście ciekawi, jakie zalety dla piszących w Kotlinie będzie miał Project Loom, to na kt.academy pojawił się artykuł Running Kotlin coroutines on Project Loom’s virtual threads, pokazujący jak już dzisiaj można się całością pobawić.
Źródła
- Prototype Loom-based concurrency API for Scala
- Will Loom Kill Kotlin Coroutines?
- Running Kotlin coroutines on Project Loom’s virtual threads
- Helidon Nima 4.0 ALPHA4
3. Czyżby Valhalla miała przynieść lepsze wsparcie nullowalności w Javie?
Na koniec zajmiemy się Valhallą. Po okresie ciszy, projekt zaczął ponownie publikować aktualizacje. Ostatnia jest na tyle interesująca, że pomimo bardzo wczesnego etapu dyskusji warto o niej tutaj pokrótce wspomnieć.
Jedną z funkcji języka, które dostarczyć ma Valhalla są Value Type (czy jak one się tam teraz po kolejnych iteracjach mają nazywać). Głównym rozróżnieniem między „typem referencyjnym” (czyli obecnie istniejącymi w języku) a „typem wartości” jest fakt, że te drugie nie mogą przyjmować wartości null. W odróżnieniu od takiego Kotlina, własność ta nie jest łatwo wyrażalna w samym języku. Dlatego też projektanci do Valhalli rozważają wprowadzenie nowego znacznika „nullness” dla obiektów.
Nowa funkcja ma pozwolić obiektom jasno oznaczać, czy dopuszczają nullowalność czy nie i zachowywać tą informację w runtime. Dzięki temu JVM będzie w stanie optymalizować sposób ich przechowywania w heapie. Na razie nie ma propozycji konkretnego syntaxu, dla uproszczenia twórcy w korespondencji używają składni zbliżonej do Kotlinowej (Foo!
jako non-null Foo i Foo?
dla wariantu Foo
lub null). Jest to jednak jeszcze bardzo wczesny etap, a twórcy nie wykluczają jednak użycia do tego celu jakiejś adnotacji pokroju @NonNull
.
A jak już nam wyszło, że w każdej sekcji nawiązujemy do Kotlina – to podobnie jak w przypadku Wirtualnych Wątków, inne języki używające Javy jako Hosta mogą na tym tylko zyskać. Twórcy JVM zamierzają bowiem wykorzystać znaczniki min. do lepszego zarządzania pamięcią na poziomie samej maszyny wirtualnej.
Przypływ podnosi wszystkie łodzie.
Wartościową dyskusję nad proposalem znajdziecie na reddicie
Źródła
Zainstaluj teraz i czytaj tylko dobre teksty!
PS: Ukazał się raport The State of Spring 2022
Przebiłem się przez raport, i raczej nie ma w nim niczego rewolucyjnego, ale podzielę się z Wami dwoma faktami, które przykuły moje oczy.
Po pierwsze, 35% użytkowników Springa deklaruje używanie jego reaktywnej wersji. Ciekawym jest też wzrost (choć nie jakiś olbrzymi) zastosowań Springa w rozwiązaniach Serverless.
Społeczność Springa (przynajmniej Ci, którzy o nich słyszeli) reaguje też entuzjastycznie na nowości w Javie. 90% mających świadomość istnienia Looma chciałaby móc używać go w Springu, a GraalVM jest na radarze aż 98%. Entuzjazm jest, ciekawe ilu osobom rzeczywiście uda się wprowadzić natywne obrazy na produkcję.