Kotlin 1.8 to wydanie widmo – JVM Weekly #120

1. Kotlin 1.8 – wydanie widmo

Kotlin 1.8 to strasznie dziwne wydanie Kotlina. Początkowo zapowiedziany jeszcze na listopad 2022, ostatecznie pojawił się po chichu zaraz przed sylwestrem, 28 grudnia. I pewnie to by zamknęło sprawę (w końcu nowa wersja się pojawiła), ale nowym wydaniom Kotlina towarzyszył zawsze post na (milczącym od połowy grudnia) oficjalnym blogu języka prowadzonym przez JetBrains, tutoriale video i ogólnie spora ilość materiałów dodatkowych. Nie tym razem.

Początkowo myślałem, że takowe pojawią się po prostu początkiem stycznia, ale mamy już połowę miesiąca, a tutaj wciąż nic. Całość sytuacji w zabawny sposób dopełnia zaś wpisanie Kotlin 1.8 w Google. Na jednej ze szczytowych pozycji znajduje się strona is.kotlin.released.info, która jako datę premiery pokazuje… Kwiecień 2023. Nie jest to oficjalna publikacja, żebym miał ją fact-checkować, ale dokłada się jeszcze do ogólnego wrażenia, że to nowe wydanie Kotlina jest jakieś takie… opuszczone. Kotlin 1.8 się jednak ukazał, więc możemy przyglądnąć się, co ciekawego przynosi.

Jak zwykle skupimy się tutaj głównie na zmianach dotyczących edycji JVM-owej. Zacznijmy więc od tego, że nowy Kotlin to pierwsza wersja ze wsparciem dla Javy 19. Przesunięta została też dolna granica wsparcia. Jeśli używaliście Kotlina w środowiskach, gdzie maksymalną dopuszczalną wersją Javy była wersja 1.7, mam dla Was złą nowinę – od wersji 1.8, minimalna wspierana wersja JDK to również 1.8 (przynajmniej łatwo zapamiętać). Pozwoliło to min. na przyspieszenie mechanizmu refleksji. W ramach czyszczenia kodu, usunięto również starą reprezentacje pośrednią, pozostającą w uśpieniu już od wersji Kotlin 1.5.

Kotlin doczekał się też nowej flagi do debugowania – -Xdebug. Jej rolą jest wyłączenie niektórych optymalizacji dokonywanych przez runtime języka, które utrudniały zrozumienie zachowania kodu min. podczas wykonywania korutyn.

Jestem prostym człowiekiem, ale przyznam, że z całego wydania najbardziej urzekło mnie Support for Lombok’s @Builder annotation. Kiedy pierwszy raz migrowałem się z dużego projektu napisanego w Javie na Kotlina, to właśnie brak wsparcia dla @Builder z Lomboka był najbardziej czasochłonną, manualną robotą. Z perspektywy przyznaje, że adnotacja ta w Kotlinie nie jest do niczego potrzebna, ale brak wsparcia dla niej bardzo utrudniał stopniową migrację projektów mocno bazujących na Lomboku.

Tak naprawdę jednak najwięcej zmian doczekała się integracja z Gradle. Kotlin otrzymał bowiem pełne wsparcie dla funkcjonalności dostarczonych przez Gradle 7.2 i 7.3. Jest tego sporo, w większości to jednak szczegóły, więc zainteresowanych odsyłam do odpowiedniej sekcji oficjalnych release notes.

Pozostałe rzeczy, jak np. lekkie zmiany w bibliotece standardowej, to już raczej detale. Mam więc wrażenie, że Kotlin 1.8 w związku z tym nie zapisze się raczej jakoś mocno w szerszej świadomości, chyba że programistom Swift/ObjectiveC – języki te doczekały się podobno znacznie lepszego mechanizmu kompatybilności.

Co ciekawe, wspomniane początkiem artykułu milczenie dotyczy nie tylko najnowszego wydania Kotlina, ale również Roadmapy projektu. Ta również w grudniu 2022 otrzymała bowiem swoją aktualizację. Priorytety się nie zmieniają – w dalszym ciągu kluczowe miejsce zajmuje nowy kompilator K2 i stabilizacja Kotlin Multiplatform Mobile. Pojawiło się jednak kilka nowych pozycji, jak publiczne wypuszczenie plugina dla K2 do IntelliJ czy wsparcie twórców bibliotek zewnętrznych. Ci ostatni otrzymać mają ulepszenie KDoc oraz oficjalne guidelines dla API, pokrywające przykładowo dobre praktyki tworzenia projektów multiplaformowych, zasady publikowania artefaktów czy też zapewnienie wstecznej kompatybilności.

To żeby domknąć już temat Kotlina i wejść w 2023 na pozytywnej nucie – pojawił się oficjalny line-up speakerów na KotlinConf 2023. Jeżeli zastanawiacie się więc nad wybraniem się w kwietniu do Amsterdamu, teraz możecie sprawdzić, kogo będzie się dało tam posłuchać.

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. MicroProfile (jednak) łączy się z Core Profile

O ile Kotlin 1.8 to jeszcze pozostałości po 2022, w bieżącym tygodniu ukazała się pierwsza duża premiera roku 2023 – MicroProfile 6.0. Ten, poza standaryzacją nowego zestawu API, przynosi zaś oczekiwane uporządkowanie tego, jak wygląda obecnie relacja projektu z Jakarta EE.

Wraz z Jakarta EE 10 pojawił się tak zwany Core Profile – zestaw API, które zgodnie z planami twórców mają stanowić minimum niezbędne do tworzenia mikrousług w Javie. Brzmi to bardzo podobnie do celu, jaki postawili sobie twórcy MicroProfile, dlatego od początku zastanawialiśmy się, w jaki sposób pojawienie się Core Profile na niego wpłynie. Jakaś forma synergii wydawała się tutaj być bardzo naturalna, ale równocześnie od początku pojawiały się jasne komunikaty, że nie należy spodziewać się dwóch inicjatyw w jedną. Ich twórcy jednak zapewniali, że pozostają ze sobą w stałym kontakcie i w przyjacielskich stosunkach.

Teraz zaś wraz z premierą MicroProfile 6.0 dowiadujemy się, jak splecione zostaną oba standardy. Dotychczasową strategią MicroProfile było wybieranie sobie z Jakarta EE tych API, które według twórców projektu miały być najbardziej przydatne dla użytkownika MP. W wypadku MicroProfile 5.0 było to więc:

• Jakarta Contexts and Dependency Injection (CDI)
• Jakarta Annotations (JPA)
• Jakarta RESTful Web Services (JAX-RS)
• Jakarta JSON Binding (JSON-B)
• Jakarta JSON Processing (JSON-P)

Od wydania MicroProfile 6.0 projekt dokonał alignementu z Jakarta Core Profile. Oznacza to, że zamiast na pojedynczych API będzie on posiadał zależność na pełnym Profilu, a tranzytywne trafią do niego również następujące API:

• Jakarta RESTful Web Services
• Jakarta Interceptors

Ze zrozumiałych powodów, minimalna wersja Jakarta EE wspierana przez MicroProfile to teraz Jakarta EE 10.

Oprócz powyższych, MicroProfile 6.0 to też zmiany związane z Observability, wymuszone przez działania „podmiotów zewnętrznych”. Jeśli chodzi o Tracing – śledzenia poszczególnych zdarzeń w ramach aplikacji – organizacją zajmującą się tworzeniem standardów jest Cloud Native Computing Foundation (w skrócie CNCF). Przez lata rozwijane było kilka konkurencyjnych projektów, takich jak OpenCensus czy OpenTracing. Ten ostatni trafił zresztą do MicroProfile jako MicroProfile OpenTracing API.

CNCF początkiem zeszłego roku zdecydował się jednak na porzucenie rozwoju OpenTracingu na rzecz OpenTelemetry, będącego nieco szerszym projektem. W wyniku tego, MicroProfile OpenTracing API oberwało rykoszetem i również przestanie być wspierane. Na jego miejsce powstało MicroProfile Telemetry Tracing, implementujące standard Tracingu pochodzący OpenTelemetry.

Co istotne, OpenTelemetry wprowadza też własny standard dla metryk, którego jednak MicroProfile nie zdecydował się wspierać, stawiając na autorskie MicroProfile Metrics. Prowadzi to do kuriozalnych sytuacji, gdy takie projekty jak np. Quarkus, chcąc w pełni wspierać standard OpenTelemetry zmuszone są porzucać niekompatybilne z nim MicroProfile Metrics – więcej o sytuacji poczytacie tutaj. Podejrzewam więc, że to nie koniec zmian i w przyszłości czeka nas dalsza ewolucja relacji MicroProfile/OpenTelemetry.