Czy Kotlin dalej ma coś do zaoferowania programistom Javy? - JVM Weekly 107

1. Kotlin 1.7.20 wydany

Od kiedy pierwszy raz informowaliśmy o wersji Beta końcem lipca trochę czasu już minęło, ale w końcu Kotlin 1.7.20 trafia w nasze łapy. Wersje 1.x.20 zawsze były istotnymi, stanowiąc ostatni przystanek prze kolejnym „dużym” wydaniem. Czy również 1.7.20 przynosi ze sobą istotne zmiany?

Tym razem mocno jak nigdy…

No bo trochę ciężko inaczej mówić o wydaniu Kot nc lina, którego główną nowością jest dodanie do eksperymentalnego kompilatora eksperymentalnych pluginów. K2, bo oczywiście o niej tutaj mowa, zbliżyła się w ten sposób w kierunku wersji produkcyjnej. Słowem klucz jest jednak tutaj „zbliżyła”. O ile bardzo czekam na K2 i wierze, że może być dla Kotlina swoistym nowym rozdaniem, o tyle naprawdę ciężko by mi było komuś rekomendować upgrade wersji wyłącznie z powodu tej nowości. Wsparcie wspomnianych pluginów kompilatora, takie jak all-open, no-arg czy Lombok sprawia, że wiele projektów wreszcie będzie mogło w miarę bezwysiłkowo zweryfikować, na ile K2 rzeczywiście sprawdza się w ich przypadkach użycia. Twórcom Kotlina da to z pewnością masę wartościowego feedbacku.

Oczywiście, jak to w wypadku K2, na razie wszystkie te nowości dotyczą tylko Kotlina odpalanego na JVM (zresztą właśnie ta edycja otrzymała w 1.7.20 kilka innych eksperymentalnych nowości, głównie wydajnościowych). Kotlin to jednak dzisiaj znacznie więcej niż JVM. Dlatego też inną, równie hermetyczną, acz istotną zmianą pod maską 1.7.20 jest ostateczne „przyklepnięcie” nowego managera pamięci dla Kotlin Native. Ten przewijał się w wersjach testowych już od kilku wydań, ale ostatecznie twórcy uznali, że jest on gotowy na produkcyjny prime-time. Nowy sposób zarządzania pamięcią ma znacznie usprawnić pracę z korutynami, a także dzielenie kodu między iOSem, a Androidem. Z tej perspektywy, stanowi więc (podobnie jak wcześniej przywoływana K2) kamień milowy dla projektu Kotlin Multiplatform.

No tak, ale co z tego wydania będzie miał „zwykły” użytkownik Kotlina? No cóż… w sumie nic.

Nie, drogi ..<, nie jesteś. Ale też ciężko uznać Cię za coś, co wywróci życie programistów, zwłaszcza, że wsparcie syntaktyczne dla niedomkniętych zakresów:

when (value) {
    in 0.0..<0.25 -> // first quarter
    in 0.25..<0.5 -> // second quarter
    in 0.5..<0.75 -> // third quarter
    in 0.75..1.0 ->  // last quarter  <- note closed range here
}

pozostaje eksperymentalnym „featurem”. Podobnie będzie pewnie z data object, nowym typem danych, który od zwykłego object różni się wyłącznie lepszą reprezentacją toString… i również pozostaje eksperymentalne.

Jeśli lubicie format video – to jak zwykle Sebastian Aigner z JetBrains przygotowało takie podsumowanie wydania. Własnego osobnego wideo doczekał się zaś wspomniany ..<

Źródła

2. Co Kotlin ma jeszcze do zaoferowania programistom Javy?

Dla wszystkich tych, którzy odczytali moje dywagacje na temat nowego wydania Kotlina jako coś mocno negatywnego – śpieszę tutaj z wyjaśnieniami. Ja Kotlina naprawdę bardzo lubię i traktuje go jako realny „inkrement” nad Javą. Problem polega na tym, że jego twórcy zrobili na tyle dobrą robotę w kilku pierwszych edycjach, że ciężko wprowadzić teraz jakąś znaczącą rewolucję. Z drugiej strony, twórców projektu dopadł chyba trochę… dług techniczny, stąd tak wiele nowych rzeczy dotyka raczej aspektów mało widocznych dla przeciętnego programisty.

A przynajmniej nie w suchych release notes, bo to właśnie prędkość kompilacji w dalszym ciągu pozostaje bolączką Kotlina, mimo niesamowitego kroku naprzód w stosunku do moich pierwszych eksperymentów jeszcze w 2018.

Sprawia to, że od dawna nie mieliśmy w Kotlinie czegoś, co zrobiłoby jakieś większe wrażenie i szum, a swoista „ucieczka” w Multiplatform też się nieco przeciąga. Nie byłoby w tym pewnie nic szczególnie dla języka niepokojącego, gdyby nie to jak mocno wpłynął on na konkurencję, w szczególności tą najbliższą – chodzi mi oczywiście o Java.

Żeby nie było, że to tylko mój DoomSaying – pod koniec 2019 roku Jake Wharton – świetnie znany w społeczności Androidowej – opublikował zbiór przewidywań na temat tego, jak szybko Java będzie w stanie nadganiać swojego młodszego kuzyna. W oparciu na dostępne w owym czasie JEPy zastanawiał się, które z istniejących wtedy przewag Kotlina będą ciągle realnymi przy premierze Javy 19. A że ta miała właśnie miejsce, przyszedł czas podsumowań. Te są zaś bardzo… interesujące.

Okazuje się bowiem, że ze wszystkich dyskutowanych onegdaj funkcjonalności (Bloki Tekstu, Rekordy, Sealed Classy czy wirtualne wątki), jedyna która nie została „dowieziona” to Lokalne Metody – wszystkie inne możemy już w Javie używać. Tekst Jake kończy się raczej na pozytywnej nucie (Kotlin w końcu od tamtej pory też wprowadził trochę nowości), ale coraz trudniejszym wydaje się być przekonanie programistów Java do migracji – po prostu z roku na rok, inwestycja w nowy ekosystem daje coraz mniej.

Aczkolwiek ja w dalszym razie uwielbiam Kotlina za jego podejście do nie-nullowalnych typów. I tego Java nam chyba nigdy nie da.

A sytuacja nabiera tempa. Już po publikacji tekstu Whartona, regularnie pojawiający się w tych przeglądach Brian Goetz opublikował duży tekst o znamiennym tytule „Brukowanie rampy wejściowej” („Paving the on-ramp”), wpisującego się w Project Amber. W ramach publikacji dokonuje on analizy, co tak naprawdę musiałoby stać się z językiem, aby ten stał się przyjemniejszy dla początkujących. Kanwą całości jest próba przejścia z:

public class HelloWorld { 
    public static void main(String[] args) { 
        System.out.println("Hello World");
    }
}

void main() {
    println("Hello World");
}

A więc „prawie” maksymalnego uproszczenia składni języka. Jak się okazuje, nie jest to coś niewykonalnego – Brian w klarowny sposób przedstawiam jakie kolejne kroki musiałyby zostać wykonane, aby ostatecznie dojść do wspomnianego celu. Po drodze musiałoby się pojawić kilka nowych funkcji języka (jak nienazwane klasy czy też predefiniowane statyczne importy), a sporym zmianom musiałby ulec tak zwany „launch protocol”, czyli zbiór zasad mówiących, które metody mogą stanowić punkt uruchomieniowy dla javowych programów.

Polecam lekturę publikacji, ponieważ jest ona zarówno przystępna, jak i pełna interesujących detali dla każdego, kto jest ciekawy procesu, w ramach którego przebiega ewolucja języka takiego jak Java. Dodatkowo, tekst pomaga też zrozumieć idee stojące za nieco mniej znanymi funkcjami języka jak np. JShell.

Dla fanów Kotlina będzie stanowił zaś po raz kolejny dowód, jak bardzo „inspirującym” stał się ich język dla całej JVMowej społeczności.

Źródła

3. Jak wygląda użycie Javy w Microsoft

A na koniec krótko o korporacyjnym PDFie od Microsoftu. Firma z Redmond zdecydowała się bowiem pochwalić wszystkim tym, co robi dla społeczności…

Czytaj – rzuca dolarami we wszystkie główne około-javowe projekty

…ale również tym, co z niej bierze. Mamy więc okazje dowiedzieć się, w których projektach Microsoftu realnie używana jest Java. Okazuje się, że jest ich naprawdę sporo, aczkolwiek z mojej strony ciekawsze niż sam fakt użycia są powody, dlaczego w konkretnych projektach pojawia się akurat Java.

Można bowiem wyróżnić dwa schematy. Z jednej strony, taki Bing czy Azure weszły w Javę ze względu na charakterystyczny workload projektów – oba z nich opierają się na ekosystemach wymagających w jakimś stopniu JVM lub dobrze się z nim integrujących – Kafka, Hadoop, Spark czy Zookeeper to tylko niektóre z wymienionych w dokumencie. Z drugiej strony, gro projektów zostało niejako zakupione z Javą na doczepkę – na tej technologii opierał się LinkedIn, Yammer czy też Minecraft. Pokazuje to tylko, jak bardzo akwizycja może wpłynąć na ewolucję stacku technologicznego w firmie, nawet tak dużej jak Microsoft.