Devoxx 2018

Po letech jsem se byl podívat na Devoxxu, takže je na čase oprášit na blogu pavučiny a zapsat si, co jsem se naučil.

Reactive vs. Loom

Nejvíc mě dostala prezentace o projektu Loom. Na současném přístupu ke škálování mi cosi nesedělo, ale nedokázal jsem pojmenovat co. Pár firem potřebuje opravdu škálovat, a proto všichni musí začít připisovat knihovny na to, aby podporovaly RxJavu, Reactor a podobné. Musíme přepsat databázové ovladače, HTTP knihovny, přístup k souborovému systému tak, aby byl reaktivní. Za to se nám dostane té odměny, že už nebudeme muset psát v Javě, ale v jakémsi DSL, kterým budeme krásně skládat asynchronní potrubí.

Když se nad tím zamyslíte, tak je to neuvěřitelně prosakující abstrakce. Abych ji mohl použít, musím moji asynchronní knihovnu zadrátovat do API. Takže metody už nevrací T ale Mono<T>. To není prosakující abstrakce, ale cedník.

V projektu Loom si chlapci v Oraclu řekli, že to jde možná dělat lépe. Co nám vadí na vláknech? Jsou drahá, žerou paměť a jsou zbytečně blokována při čekání na sít, souborový systém nebo zámek. Co kdybychom použili jinou abstrakci, říkejme jí třeba Fiber (nitka?). Nitka se veze na vlákně, ale když narazí na blokující operaci, tak se vlákna pustí a to může jít vozit jiné nitky. Když blokující operace skončí, blokovaná nitka naskočí na jiné vlákno a provádí další můj kód. Jelikož se všechny blokující operace obvykle provádí skrz standardní Java knihovnu, kód který řeší opuštění vlákna a opětovné naskočení zpět je schovaný v JVM a jeho knihovnách. Já nemusím nic řešit. (Kdo můj poetický popis nepochopil, nechť se stydí a pustí si video).

To znamená, že jako programátor dostanu škálování v podstatě zadarmo. Můžu dál psát svůj staromódní imperativní kód a JVM zajistí, že to poběží efektivně. Samozřejmě nedostanu všechny výhody reaktivního přístupu jako backpressure (protitlak), ale možná mi to za čistší API, čitelné stack tracy a jiný konfort, na který jsem zvyklý, stojí.

Na Dovoxxu ukazovali zajímavé demo, kde vzali Jetty, místo ThreadPoolu podvrhli něco co používá Fibers a když to zrovna nespadlo, tak klasická aplikace v JAX-RS škálovala jako divá. Bohužel bude ještě pár let trvat, než dořeší všechny detaily jako ThreadLocals a podobně, ale vypadá to nadějně.

Trochu s tím rezonovala přednáška o Briana Goetze o Objektovém a funkcionálním programování. Síla objektového programování je v místech, které překračují hranice (boundaries). Tam potřebuji mít silný kontrakt v čemž OOP exceluje. Uvnitř hranic dává občas smysl zahodit ceremonii s objekty spojenou a využít sílu FP.

Nejlepší přednášky:

Co říci závěrem? Devoxx je super konference, člověk si rozšíří obzory, uvědomí si, jak moc ho programování baví a jak živý je Java ekosystém. Až na pár ojedinělých výjimek byly všechny přednášky skvělé, takže několikrát litoval, že se nemůžu rozkrájet a jít do víc sálů najednou. Nevadí, 10 Mistakes Hackers Want You to Make si pustím z YouTube.

One Response to “Devoxx 2018”

  1. Aleš Roubíček Says:

    Trochu mě udivuje jakým způsobem se RxJava a její deriváty používá. Původní myšlenka Rx (LINQ to Events) byla, že Rx používáš jako top level DSL pro zkrocení různorodých asynchronních APIs. Java de facto asynchronicitu nemá. Má pouze thready. Není žádný důvod, nechat RxJavu prosakovat do vašich APIs a do dalších low level vrstev. Všechno to jen zesložiťuje a doslova kurví návrh. 🙂 Když se mi chudák kolega snažil vysvětlit kus kódu v RxKotlin a všechny automagický generátory kódu a stovky vrstev čehosi, jak aby uspokojili potřebay Androidu, Rx a kdoví čeho ještě, málem mi praskla hlava. Opravdu takhle chce někdo programovat? Proč, proboha?

Leave a Reply