Zakotlíme, uvidíme

Stejně jako asi většina javistů jsem Kotlin poprvé zaregistroval pár let předtím, než se s velikou pompou dočkal oficiální podpory Googlu coby primární androidí jazyk. Vzhledem k tomu, že jsem v té době necítil potřebu napsat si vlastní plug-in pro Ideu (což byl tehdy, alespoň z pohledu zvenku, asi takový nejtypičtější use-case pro Kotlin), nevěnoval jsem novému jazyku příliš pozornosti. Přece jen - s JVM jazyky se jednu dobu roztrhl pytel a člověk má jen určité množství času a investovat ho do něčeho, co za půl roku beztak vyjde z módy (a přestane se vyvíjet), mě úplně nelákalo. 

Asi nejsem sám, kdo to tak má, ale i když příklon Googlu k nějaké technologii nemusí nutně vypovídat o její technologické kvalitě a vlastně už vůbec nemusí být žádnou zárukou stability a budoucí existence (každému z nás už jistě Google bez náhrady zařízl jeho oblíbenou službu...), začal jsem v tu chvíli více věřit tomu, že Kotlin hned tak nezmizí a nezestárne. 

Inu, prolétnul jsem dokumentaci, pár článků a příkladů, napsal si pár vyumělkovaných cvičení a hurá na věc....

Vlastně ne tak zhurta... Jak už to tak bývá, nové projekty nerostou na stromech - a i kdyby, pustit se v novém jazyce s celým týmem do něčeho, co má nějaký rozpočet a nějaké deadliny, může přinést nemilé vystřízlivění; navíc - když někomu slíbíte aplikaci v Javě, tak mu buď můžete dodat aplikaci v Javě, nebo vysvětlovat něco o JVM a bytecodu :-) A tak dalších pár let až na občasné pokusy nic moc. 

Asi před dvěma lety jsem pracoval na projektu, kde se používal Lombok. Má to své limity a ne vždy to přináší jen užitek, ale na některé věci se zvyká rychle. Od té doby mě začalo iritovat (obzvlášť u větších tříd) psát nebo generovat gettery a settery. A tak se na scénu vrací Kotlin, který se - jak známo - snaží "boilerplate" kód co nejvíce omezovat. Konkrétně se pro tento účel skvěle hodí tzv. data classes.

Pro porovnání:

Java:

`<p>CODE: https://gist.github.com/Duck28/fb5d6d1b33557ccf4b920d62c71820c3.js</p>`

‍

Kotlin:

`<p>CODE: https://gist.github.com/Duck28/a2709774730998c8e08e06e27a585cce.js</p>`

‍

Uvedený příklad je samozřejmě trochu demagogický, ne vždy potřebujeme od obyčejné POJO třídy veškerou “prémiovou” funkcionalitu, navíc za každého rozumného programátora (masochisté prominou) většinu dřiny vykoná IDE. Ale pro ilustraci to asi stačí - Kotlin je zjevně mnohem méně ukecaný. A i když v Javě většinu mechanické práce zařídí generátor, tak proč tam ten kód vůbec mít?

Samozřejmě by stálo za to využít výhod a pohodlí Kotlinu ve větší míře (u data classes benefity ani zdaleka nekončí, ale o tom zase až někdy příště) a napsat v něm např. ucelený modul, nicméně jako začátek i tohle není špatné. Výhodou nastíněného opatrného přístupu je, že jej můžete začít používat na své stávající Java aplikaci klidně hned dneska (a pořád v podstatě máte Java aplikaci). Stačí přidat jeden malý krůček do buildu a od zítřka můžete začít šetřit klávesnici a své karpální tunely.

V Gradlu to může vypadat cca nějak takle, YMMV:

`<p>CODE: https://gist.github.com/Duck28/a338adac1dee9b013afa8f1701400766.js</p>`

‍

Zároveň tím získáváte možnost kdykoliv nějakou třídu přepsat do Kotlinu, pokud k tomu budete mít důvod či náladu. Mimochodem, pokud používáte IntelliJ IDEA, může značnou část práce udělat za vás:

‍

‍

‍

Neodpustím si jedno malé varování - nic se nemá přehánět a tak se ani data classes v každé situaci. Jeden příklad za všechny jsou třeba Hibernate entity. Tím, že “ztrácíte kontrolu” nad implementacemi equals, hashCode a toString si snadno neuvědomíte, že pracují se všemi fieldy a nezabrání jim v tom ani fakt, že jsou lazy-loaded. V kódu pak někde bezelstně porovnáte dvě entity, použijete hash mapu, nebo si někam zalogujete obsah entity a způsobíte nepříjemný side-effect - začnete spouštět další query nad databází (nebo vám vylítne LazyInitializationException).

To by pro dnešek bylo vše. Na cestu vám ještě přidám odkaz, kde začít a můžete se vesele pustit do kotlení :-)