Vlákno názorů k článku Vyšla Java 11: menší core systém a experimentálne garbage collectory od Novy gc - Uz od javy 8 slysim, jak je GC...

Já bych na to vůbec nevsázel, myslím, že Java tu bude ještě dlouho po té, co Kotlin zůstane kuriozitou pro pár fandů. Kotlin bych bral spíš jako prototyp, otestují se na něm nějaké věci, a pak přijde něco dalšího, kde budou převzaté věci z Kotlinu, které se osvědčily, a zapomene se na ty, které se nepovedly. Na Kotlinu je až příliš vidět, že je to jazyk psaný odspoda, programátory – chybí tam akademický nadhled, nějaký přesah. Kotlin vypadá, jako když pejsek a kočička vařili dort – aby byl dort dobrý, dali do něj všechno dobré. Akorát ty dílčí dobré věci nefungují spolu navzájem.

Nashorn byl jen náhradou za Rhino, ne něčím kompletně novým.

. (neregistrovaný), 11:40: Porovnávat jazyk a součásti standardní běhové knihovny je jako porovnávat hrušky s přepravkou. Java má od verze 6 podporu skriptovacích jazyků (JSR-223), přímo součástí standardní knihovny JRE byl interpret JavaScriptu Rhino, který byl v JRE 8 nahrazen interpretrem Nashorn. Pokud dál chcete používat JavaScript pomocí JSR-223, budete muset k aplikaci přibalit interpret jako knihovnu, to je vše. Ale pokud to s JavaScriptem v kombinaci s Javou myslíte vážně, podívejte se raději na GraalVM, protože to je budoucnost kombinace Java+JavaScript (a dalších jazyků). Nedává moc smysl udržovat interpret JavaScriptu jako součást standardní knihovny, když máte podporu JavaScriptu zabudovanou přímo v JVM.

Asi nemá moc smysl udržovat něco, co se plánuje nahradit něčím lepším [1] (použitelné v pohodě už dnes).

[1] https://github.com/graalvm/graaljs

Například data classes nemohou být open (i když od verze 1.1 aspoň mohou být samy zděděné). Chápu proč to tak je, ale je to přesně ten přístup „přidáme dobrou věc, a už neřešíme, jak spolupracuje se ostatními dobrými věcmi“. Nebo při inicializaci property v primárním konstruktoru nejde použít delegated properties. Opět – inicializace property v primárním konstruktoru je pěkný syntaktický cukřík, delegované properties také. Ale neřeší se, co se stane, když to někdo bude chtít použít dohromady. Vlastně by to jít použít mělo, v dokumentaci jsem nenašel nic o tom, že to nejde, ale kompilátor to prostě nepřeloží, je to neznámá syntaxe. Víc mne z hlavy nenapadá, narazil jsem ještě asi na jeden nebo dva případy během snahy napsat reálný kód. Pak jsem si ještě procházel dokumentaci, a tam přímo bilo do očí, jak každá ta jednotlivá vlastnost je popsaná samostatně s několikařádkovým příkladem, kde je použitá přesně ta jediná vlastnost (pokud možno porovnaná s Javou), ale nikde tam nejsou větší příklady, kde by to bylo zkombinované. Nemůžu si pomoci, ale na mne z toho čiší postup vzniku „hm, tohle mne v Javě nebaví, to by šlo udělat lépe, přidáme na tuhle specialitu novou vlastnost do jazyka“.
Nápady jsou to často hezké, Kotlin se nepochybně nějakou dobu používat bude a určitě bude inspirací pro další jazyky, ale je až příliš viditelné, že je to Java se spoustou záplat. Navíc nemám rád jazyky, které mají tak košatou syntaxi a kdejaké zjednodušení se řeší přímo na úrovni jazyka. (Pro mne už je mírně za hranou Groovy, a Kotlin jde ještě podstatně dál.) Javě se vytýká, že je ukecaná, protože samotný jazyk je vlastně velmi jednoduchý a spousta věcí se řeší až v runtime knihovně. Jenže ono to má tu výhodu, že se pak knihovna může měnit a vyvíjet, nové konstrukce si může přidávat vlastně kdokoli, a jazyk je pořád stejný. Třeba když porovnám null safety, Kotlin si vystačí s jedním až dvěma znaky, Java má Optional<>. Jenže Optional<> mohl do Javy zavést kdokoli, stačilo napsat normální knihovnu (a různé knihovny podobnou funkcionalitu měly). Když se v budoucnosti ukáže, že by se to dalo řešit lépe, vymyslí někdo třeba inverzní třídu Mandatory<>, a na syntaxi Javy se nemusí měnit nic. V Kotlinu budou shánět další symbol – a hlavně takovou novinku mohou zavést jenom autoři Kotlinu, nikdo jiný.

Zrovna Optional je trochu nešťastný příklad:

* Může to teoreticky implementovat kdokoliv, ale úspěch zde dost závisí na tom, aby se to široce používalo. Ve Scale se to s podobným typem Option podařilo, v Javě zatím ne. Kdyby to někdo implementoval jako 3rd party knihovnu, šance na přijetí by byly IMHO celkem mizivé.
* V jazyce bez hodnoty null by to byla fajn věc, v Javě mám ve výsledku proměnnou, která kromě Optional.of(value) může obsahovat nejen Optional.empty(), ale také null. (Ve Scale je to ještě o kousek dál: Some(value), None, null a navíc Some(null).) V tomto směru je podpora přímo v jazyce elegantnější, nenabízí žádné podivné hodnoty, které nechceme.

Tím nepopírám výhody implementace fíčur jako knihovny (ostatně Scala je na tomto principu postavená), čistě jen vyzdvihuju nevhodně zvolený příklad.

Šlo jen o porovnání toho, že je nějaká vlastnost implementována jako běžná třída, nebo že je implementována jako speciální operátory. Ostatně Kotlin má úplně stejný problém, pokud se v Kotlinovém kódu bude používat spousta Java knihoven, ze kterých Kotlin nebude schopen zjistit nullabilitu, bude jeho null safety také neúspěšné. Dichotomie mezi null a Optional.empty() je daná prostě tím, že Optional bylo zavedeno dodatečně.
Zkuste si to představit tak, že byste vytvářel nový jazyk, a rozhodoval se, zda null safety implementujete jako třídu Optional nebo jako „operátor“ otazník.

Jsou pěkné argumenty pro Optional, ve Scale to ostatně celkem dobře funguje (dokud se nedotknu Javové knihovny s null), protože se tam null prakticky nepoužívá. Scala se z Javových API snaží napřímo používat co možná nejméně, spíše přes nějaký wrapper. Ve výsledku máme i celkem dobrou iluzi, že null neexistuje, a Option může dobře fungovat… Je to ale zásluha celého ekosystému, ne jen návrhu samotného typu v Javě.

V konzervativnější Javě s dekádami dědictví to ale s přechodem na Optional tak dobré už není. Máme – i v JRE – spoustu tříd, které prostě používají null, a nelze to jen tak změnit kvůli zpětné kompatibilitě.

U Kotlinu můžeme mít horší nebo lepší podporu v závislosti na tom, jestli jsou parametry a návratové hodnoty označeny anotacemi jako @Nullable a @NonNull (či podobnými). I bez těchto anotací by IMHO mělo jít využít některé výhody nových operátorů (např. Elvis operator), jen prostě kompilátor nebude tak přesně varovat. Navíc ten kód lze průběžně o anotace obohacovat, aniž bych rozbíjel kompatibilitu. To se o Optional říct nedá.

> Zkuste si to představit tak, že byste vytvářel nový jazyk, a rozhodoval se, zda null safety implementujete jako třídu Optional nebo jako „operátor“ otazník.

To bych asi rozhodl podle cílů, jaké by ten jazyk měl. Více se mi líbí Optional, ale pokud bych měl dobře zapadnout do existujícího ekosystému (což tvůrci Kotlinu AFAIR psali jako jeden z cílů), asi by se to nějak promítlo i do jazyka. Možná bych vymyslel nějaké lepší řešení, ale těžko by se to obešlo bez nějaké speciální vlastnosti jazyka.

To bych asi rozhodl podle cílů, jaké by ten jazyk měl. Více se mi líbí Optional, ale pokud bych měl dobře zapadnout do existujícího ekosystému (což tvůrci Kotlinu AFAIR psali jako jeden z cílů), asi by se to nějak promítlo i do jazyka. Možná bych vymyslel nějaké lepší řešení, ale těžko by se to obešlo bez nějaké speciální vlastnosti jazyka.
A to je právě to, co se mi na Kotlinu nelíbí. Řeší aktuální problém, tak přidají novou konstrukci do jazyka. Jenže za dvacet let tady ten problém už dávno nebude, ale konstrukce v jazyku zůstane pořád. V Javě do stejné kategorie patří primitivní typy, ale nic moc dalšího mne nenapadá. A i ty mají nakonec aspoň tu výhodu, že jsou not-null.

Upravený příklad z dokumentace by vypadal takto
Jenže v tomhle příkladu právě delegát není definován v konstruktoru. Ta celá syntaxe s klíčovým slovem by při deklaraci property v konstruktoru nejde použít, takže jsou v jazyce dvě velmi podobné konstrukce – deklarace property v těle třídy a deklarace v konstruktoru. Ve spoustě případů je dokonce syntaxe stejná.

V Javě pak díky zpětné kompabilitě zůstane null, Optional<> a Mandatory<>. S tím se bude určitě dobře pracovat.
Už jsem vysvětloval, že to porovnáváte nesouvisející věci. Popisujete zpětnou kompatibilitu a porovnáváte jí s novým jazykem. Já jsem ale psal o rozdílu implementace ve standardní knihovně vs. nová konstrukce v jazyce.

safe calls, toho žádná knihovna v Javě docílit nemůže
Ve skutečnosti safe calls s Optional<> můžete použít a je to implementováno pouze ve standardní knihovně, není potřeba žádná magie kompilátoru.

nemluvě o runtime overheadu pro Optional<>
To je pouze otázka implementace – když je to součástí standardní knihovny, nic nebrání kompilátoru nebo JVM dělat nad tou třídou nějakou „magii“. Třeba java.lang.String se „z venku“ také tváří jako úplně normální třída, ale kompilátor s ní občas zachází speciálním způsobem.

Kotlin uz na Androidu oficiálně nahradil Javu. Už je to snad někdy od března.
Nenahradil, pouze se vedle Javy stal oficiálně druhým podporovaným jazykem.