JVM Tuesday vol. 64 - Kotlin, Kotlin i jeszcze raz Gradle 🥫

1. Co pokazano na Kotlin Premiere 2021 🎞

Przełom października i listopada dla społeczności kotlinowej przyniósł bardzo ciekawe wydarzenie. Jetbrains przygotował bowiem Kotlin Premier Event – “rozproszony” event online, który zaprezentował najważniejsze zmiany w kotlinowym ekosystemie. Dlatego teraz zrobimy sobie mały przegląd tego, co zostało pokazane (a przynajmniej temu co przykuło moje oczy).

Dużo miejsca poświęcono serwerowej stronie Kotlina – da się zauważyć, że dla JetBrains jest to coraz istotniejszy kawałek tortu. Mieliśmy min. prezentacje Ktora 2.0 (natywnie kotlinowego frameworku webowego), który mimo, że ciągle pozostaje w Becie, to można się nim już powoli bawić. Oprócz uproszczonego API, nowa edycja wprowadza możliwość “retry’ów”, zaskakującego braku poprzednika. Ktor 2.0 to też większa modularność i zwiększenie możliwości, jakie mają twórcy zewnętrznych pluginów.. Duży nacisk położono również na wsparcie Kotlina Multiplatform – Ktor dostępny jest teraz również dla Kotlina Native. A jak już jesteśmy przy Kotlin Native, na Kotlin Premiere Event nie zabrakło też Spring Native – najnowszego członka springowej rodziny. Z prezentacji możemy dowiedzieć się nie tylko o tym, jak dobrze Kotlin spina się z natywną wersją frameworku Pivotala, ale też, że sam Spring Native to tylko etap przejściowy. Spring Boot 3.0 ma bowiem posiadać wsparcie dla GraalVM Out-of-the-Box.

Oczywiście, poza stroną serwerową nie zabrakło również informacji na temat wszystkiego, co dzieje się w Kotlinie naokoło. Zaprezentowano min. jak działa nowy, zunifikowany kompilator K2. Mogliśmy się dowiedzieć, jak dużego wzrostu wydajności całości możemy się spodziewać i w jaki sposób cała inicjatywa pomoże pchnąć projekt Kotlin Multiplatform do przodu. Multiplatform mocno się zresztą rozrasta – po raz pierwszy pokazano jego wersję dla WebAssembly.

Ostatnią dużą zapowiedzią były trzy projekty związane z Kotlinowym toolingiem. Pierwszy z nich to Kover – nowe narzędzie do liczenia pokrycia kodu. Oprócz niego pokazano też Qodane, będącego rozwiązaniem do analizy statycznej. Moją największą uwagę przykuł jednak Kotlin Symbol Processing, którego celem jest zastąpienie anotacji jako głównego sposobu na metaprogramming w Kotlinie. Narzędzie ma być szybsze od klasycznych procesorów anotacji, dawać więcej możliwości i jeszcze bardziej elastycznie spinać się z build toolami.

Źródła

2. Wydano Gradle 7.3, a Kotlin wreszcie konsumuje dodatki z poprzednich wersji 🐘

A jak już jesteśmy przy build toolach jesteśmy… druga pozycja dzisiejszego przeglądu to Gradle 7.3, który przynosi sporo interesujących nowości.

Z pewnością rzeczą, która przykuwa największą uwagę jest wsparcie dla Javy 17. Tempo rozwoju JDKa z jednej strony pewnie twórców narzędzi cieszy (bo aż przyjemnie patrzeć jak to wszystko idzie do przodu), z drugiej zaś wymaga ciągłego maintanance. Oprócz Javy, wsparcie dostała również Scala 3.

Miałem tutaj zrobić dowcip o pustym pokoju użytkowników Gradle w Scali, ale liczby pokazują nieco inną rzeczywistość.

Pozostały zmian jest naprawdę dużo – jak to zwykle bywa w przypadku Gradle. Wiele z nich to kosmetyka (jeżeli jesteście ciekawi wszystkich detali, zapraszamy do przeglądnięcia oryginalnego posta), ale moją uwagę przyciągnął szczególnie nowy sposób definiowania suit testów. Od tej pory będzie można to robić o wiele bardziej deklaratywnie, przy pomocy eleganckiego DSLa.

testing {
    suites {
        // Add a new test suite
        integrationTest(JvmTestSuite) {
            // Use JUnit Jupiter as a testing framework
            useJUnitJupiter('5.7.1')// depend on the production code for tests
        dependencies {
            implementation project
        }
    }
}
}

tasks.named('check') {
    dependsOn(testing.suites.integrationTest)
}

Oczywiście, żeby tematowi naszej edycji stała się zadość, warto wspomnieć też, jakie nowe możliwości Gradle daje programistom Kotlina. Tutaj będzie lekki “twist”, ponieważ w tym wypadku do Kotlin nadgonił, i wreszcie “skonsumował wartość” jaką dały mu wcześniejsze wersje Gradle. Od Kotlina 1.5.30 możliwe jest bowiem dużo wygodniejsze definiowanie, z jakim JDK chcemy odpalić nasz build.

tasks.register("testsOnLatestJDK") {
      val javaToolchains = project.extensions.getByType()
      javaLauncher.set(javaToolchains.launcherFor {
          // 17 is latest at the current moment
          languageVersion.set(JavaLanguageVersion.of(17))
     })
}

Co szczególnie wygodne w tym rozwiązaniu to fakt, że jeżeli nie uda się zlokalizować danej wersji JDK lokalnie, Gradle automatycznie pobierze odpowiednią edycję i wszystko skonfiguruje. Tak zwany JVM Toolchain posiada sporo więcej możliwości, więc wszystkich zainteresowanych zapraszam do oryginalnego posta prezentującego funkcjonalność który ukazał się początkiem listopad.

Źródła

3. Nowa edycja Kotlinowej Roadmapy 🗺

A na końcu, żeby całość sobie podsumować – spojrzymy w przyszłość. Zespół Kotlina opublikował bowiem kolejną iterację swojej roadmapy, która to pozwala nam spojrzeć w to jak będzie się prezentowała przyszłość języka.

Duży nacisk jest kładziony na kompilator K2, ten sam o którym wspomnieliśmy już w pierwszej sekcji. Widać wyraźnie, że dla zespołu kotlinowego stanowi on bardzo istotny aspekt przyszłości języka. Wiąże się to zresztą z coraz większym naciskiem na Kotlin Multiplatform, który również przebija się wielokrotnie przez Roadmapę. Dzięk K2 zespołowi o wiele łatwiej będzie się po prostu wyciągało części “wspólne”.

Ponownie nawiązując do Kotlin Premiere, w roadmapie znaleźć można dalszą chęć rozwoju narzędzi kotlinowych. Kover (narzędzie do obliczania pokrycia testami) oraz Dokka (tool do dokumentacji) ma doczekać się w najbliższym kwartale pierwszych publicznych wydań, a Dokka swojej stabilnej wersji. Polerka czeka też atomicfu (służące do operacji atomowych) jak i kotlinx-datetime. JetBrains powoli przygotowują się też powoli do nowego wydania Korutyn.

Ostatnim ciekawym z mojej perspektywy elementem są dalsze prace nad interoperacyjnością z Javą. Tym razem wzięto na warsztat metody statyczne. Pierwsze jaskółki tematu można było znaleźć już przy okazji ankiety z pytaniami społeczności o przyszłość języka, gdzie podniesiono problem, że tworzenie odpowiedników znanych z Javy static wymaga każdorazowego tworzenia “obiektu towarzyszącego”, co w niektórych przypadkach brzegowych było trudne, albo wręcz niemożliwe. Problem ten mają rozwiązać namespace – nowy rodzaj bez instancjowego obiektu, który jest przypisany do każdej z klas. Na razie nie mamy jeszcze przykładu w kodzie, ale bardzo czekam aby móc się tym pobawić.

Całość Roadmapy znajdziecie jak zwykle pod tym samym linkiem 😉

Źródła

PS1: Pośmialiśmy się w zeszłym tygodniu z TestContainers Cloud, a teraz zapraszam wszystkich do bardzo interesującego podcastu z jednym z twórców projektu. Można się sporo dowiedzieć o założeniach, które za nim stoją “od kuchni”.

PS2: Tak, wiem że dziś w nocy ukazał się nowy Kotlin 1.6 – ale na razie tylko w Maven Repository. Także załapie się już na następny wtorek 🔥. A szkoda, bo by tematycznie pasował bardzo do edycji 😜

PS3: Tak, wiem że dziś w nocy pokazały się pierwsze drafty z Projektem Loom. Chcę się jednak całością trochę pobawić, żeby dorzucić coś od siebie, a nie tylko przeklejać JEP 😉

Oj, spodziewajcie się sporo mięska za tydzień 🍖

JVM Tuesday vol. 64 – Kotlin, Kotlin i jeszcze raz Gradle 🥫

1. Co pokazano na Kotlin Premiere 2021 🎞

Źródła

2. Wydano Gradle 7.3, a Kotlin wreszcie konsumuje dodatki z poprzednich wersji 🐘

Źródła

3. Nowa edycja Kotlinowej Roadmapy 🗺

Źródła

Odkryj więcej świetnych treści!