Blogg

Här finns tekniska artiklar, presentationer och nyheter om arkitektur och systemutveckling. Håll dig uppdaterad, följ oss på LinkedIn

Callista medarbetare Jan Västernäs

Jesper Holmberg sammanfattar ett år med Kotlin

// Jan Västernäs

Jesper - nu har ni jobbat med Kotlin i ett år i ett skarpt projekt?
Ja, det stämmer. Det är en Spring Boot-applikation där vi skrivit all kod i backend i Kotlin. Men nästan alla andra komponenter som vi tar in är skrivna i Java. Så en intressant fråga var hur samspelet mellan dessa skulle fungera. Vi har valt bort att använda vissa Kotlin-verktyg.

Hur har det fungerat?
Hittills tycker vi i projektet att det fungerar väldigt bra. Jag har känt mig väldigt produktiv jämfört med tidigare projekt där vi använt Java. Samspelet med Java-komponenterna har fungerat mycket bra. Vi har strävat efter att skriva idiomatisk Kotlin-kod men att inte ta ut svängarna för mycket. Orsaken är att även Java-utvecklare utan Kotlin-erfarenhet skall kunna komma in i projektet på ett enkelt sätt.

Vill du ge lite mer detaljer?.

  • Kotlin som språk har många, många njutbara features som ger utvecklarnöjdhet som t.ex. type inference, string templates och object properties.
  • j00Q, gradle, mapstruct: alla verktyg har sina quirks som kanske exponeras på ett oväntat sätt i ett nytt verktyg.
  • Att använda Java-kod frän Kotlin är nästan 100% smärtfritt, men null-säkerhet är en stor fallgrop.
  • Att anropa Kotlin-kod från Java är inte riktigt lika smärtfritt.

Kan vi se ett kodexempel?

Här ser vi två egenskaper som är extremt lätta att uppnå i Kotlin, dels medför val-deklaration att metodens parametrar är immutable, dels garanterar Int-deklarationen att värdet aldrig kan vara null. Detta tycker jag ger förutsättningar för en robust kodbas! Sedan är dataklasserna ganska trevliga eftersom hashCode och och equals genereras med automatik, så det är kompletta objekt med en minimalistisk källkod.

Sedan ser vi att ?-tecknet används i Kotlin för att hantera objekt som kan vara null. Detta kan exempelvis inträffa om man anropar Java-kod vilket är en fallgrop som man måste tänka väldigt noga på. Om man anropar Java-kod så finns det ju ingen garanti för att returvärden inte är null utan det måste hanteras. Spring har dock lagt ner mycket energi på att stödja anrop från Kotlin genom att ange @Nullable på sina metoddeklarationer. Det medför att det blir kompileringsfel om man glömmer hantera null i sin Kotlin-kod.

Finns det några nackdelar som du hittat?.
Jo några, men i det stora hela är de av mindre betydelse.

  • Alla verktyg vi har valt har fungerat mycket bra, men med vissa saker som svider.
  • Många byggverktyg fungerar lite sämre och kodbasen kompilerar lite långsammare.
  • IntelliJs verktygsstöd är inte lika bra som på Java-sidan - kan bero på att ett oberoende team hos JetBrains implementerar Kotlin-stödet i IDEA.
  • Mer kryptiska felmeddelanden.
  • Kotlins annotation-processor “kapt” är opålitlig - och IntelliJs kompilator har inget stöd.
  • Rent allmänt tillhör man inte majoriteten, och har därför svårare att hitta exempel och lösningar.

Sammanfattning?
Vi är väldigt nöjda med de teknikval vi gjort i projektet.

Tack Jesper

Tack för att du läser Callistas blogg.
Hjälp oss att nå ut med information genom att dela nyheter och artiklar i ditt nätverk.

Kommentarer