Vlákno názorů k článku Nechte Go plavat, teď sviští Java od kvr kvr - Co 3rd-party package? Když budu mít závislost třeba...

Proč ne? Jestli něco ve scriptování chybí, tak je to právě staticky typovaný jazyk. Honit v runtime undefined variables v python či perl (ten je na tom ještě pořád líp kvůli povinné deklaraci) je to, co dělá vývoj extrémně neefektivní. Mít na tohle Javu, respektive rychlou Java, by na běžné skriptování vyřešilo spoustu problémů. Buď se tam dlouhodobě prosadí Java, Go nebo příšernost typu Powershell.

GraalVM je užitečný samozřejmě všude, alo AoT je na server side kontraproduktivní (pokud se po nějaké době sám nenahradí kódem z JIT). AoT na rozdíl od JIT nemá v době překladu důležité informace pro optimalizaci.

Jo ale nedefinovaný atribut objektu už běžné pythoní nástroje neodhalí. Teď si hraju s mypy, ale pořád to není: co se zkompiluje, v tom není hloupá chyba (překlep), nebo špatné použítí typu. Navíc neexistence block-scope zanáší taky různé chyby (kdo by čekal, že mimo 'for' blok bude řídící proměnná stále nadefinovaná). Osobně jsem toho napsal v Pythonu dost na to aby mě ta jeho dynamičnost bolela. Bohužel musím v některých skriptech počítat se spuštěním Pythonu 2.5 až 2.7 a to teprve bolí. Tam kde si můžu dovolit Python 3.5 (Python 3 se neměl jmenovat Python, vždyť se změnily takové základy jako třeba operátor / ) tak tam zkouším dostat mypy, a je to o řád lepší (oproti třeba Go ale stále cca třikrát horší).

Přesně to jsem měl na mysli. V perl jsou samotné proměnné vyřešené, protože se musí povinně deklarovat, navíc je vidět jejich scope (tedy při zapnutém strict). Ale stejně jako v ostatních dynamicky typovaných jazycích, pokud volám metodu nebo šahám na atribut objektu, tak tak kontrola už tam není prakticky žádná.

Co se těch nástrojů týče, tak to vystihuje celou absurditu dynamicky typovaných jazyků - na začátku se tvrdí, že vlastně statické typování není třeba a pak se přes šílené workaroundy v komentářích či anotacích snaží ty typy dostat, aby byly přístupné aspoň pro statickou analýzu, když už ne v runtime :-/

Opačný pangejt (žádné závislosti, viz kontejnery) je úplně stejně špatně. Zářným příkladem je SSL knihovna. Pokud vyvinu aplikaci a nechám ji běžet více než pět let, tak se přestane mít možnost bavit po SSL (pardon dnes se tomu říká TLS) s nejovším software. Takže je potřeba dobře oddělit to co má admin upgradovat a co může zůstat přesně ve verzi se kterou byla aplikace vyvinuta. Tam kde je šance dělat security (nebo feature) update bez zásahu vývojáře, tam se sdílené knihovny hodí. Tam, kde je potřeba nasazovat knihovnu patchnutou, nebo se stejným vývojovým cyklem jako aplikaci, tam jsou sdílené knihovny zbytečné.

Nikoli, to je právě ta mylná představa, že je možné aplikaci aktualizovat z venku, bez spolupráce autora. Nová SSL knihovna vám u pět let staré aplikace nijak nepomůže, protože ta aplikace případné nové protokoly nebude umět zapnout nebo je používat. Pokoušet se dělat security update bez zásahu vývojáře je loterie – v některých výjimečných případech to jde, ve spoustě příkladů bude bezpečnostní chyba přímo v aplikaci, a ve spoustě dalších případů bude bezpečnostní chyba ve způsobu používání knihovny, takže se opět musí opravit v aplikaci. Těžko může někdo opravdu věřit tomu, že má pět let nezáplatovanou aplikaci, ale ta aplikace je bezpečná, protože přece aplikoval bezpečnostní záplaty na knihovny.

Ve většině případů to možné je. Samozřejmě jsou díry i v aplikacích samotných, ale povětšinou ve sdílených knihovnách. Pokud je možnost upgrade globálně pro celý systém, je to mnohem efektivnější cesta. Nehledě na to, že zvláště komerční aplikace můžou být bez přístupu k jejich kódu, takže jakýkoli upgrade je komplikovaný.

Způsob, co má Java (Maven) nebo Go, není taky samospasitelný. Kromě výše uvedeného je stejně třeba poskytovat zpětnou kompatibilitu jednotlivých knihoven, bo v případě tranzitivních dependencí se jeden nebo druhý package stejně rozbije.

Aplikace či jejich závislosti si deklarují závislost na minimální verzi dané knihovny, takže případná nekompatibilita je detekována ještě v čase spuštění. Musí být zajištěna binární kompatibilita, což je o něco větší problém pro C knihovny, ještě větší pro C++, ale minimální problém pro Java s klasickým JIT. Ve chvíli, kdy upgraduju třeba z Qt3 na nekompatibilní Qt5 a mám na tom další závislost, tak se knihovna defakto stává součástí platformy, ale opět viz výše - nemůžu mít část dalších závislostí běžící s Qt3 a část s Qt5, to je problém, který existuje pořád, bez ohledu na typ balíčkování aplikace.

K tomu, aby byly díry převážně ve sdílených knihovnách, není žádný důvod. Vůbec nechápu, jak jste na něco takového přišel. Třeba chyby přetečení bufferu – to jako že aplikační programátoři umí příslušné funkce volat správně a programátoři knihoven ne? Chyby typu SQL injection budou jenom v aplikacích. Atd.

Tranzitivní závislosti nevadí, problém je, pokud na jedné knihovně závisí různé části (typicky různé knihovny nebo knihovna) a závisí na různých verzích. Jenže ona i zpětná kompatibilita má různé úrovně, a chyby se velmi často vyřeší tak, že knihovna je dál zpětně kompatibilní pro ten kód, který s chybou přímo nesouvisel. Navíc od Javy 9 jsou řešitelné i ty vícenásobné závislosti, protože modul závisí jen na modulech, které deklaruje, a závislosti jiných modulů ho neovlivňují.

Závislost jedné aplikace na Qt3 i Qt5 nemusíte jako administrátor řešit, protože ten problém vyřešil už autor té aplikace.

Ohledně bezpečnostních děr: Protože aplikace se píšou na vyšší úrovni, často ve vyšších jazycích, s použitím frameworků, které od většiny bezpečnostních chyb abstrahují. Navíc jsou poměrně časté chyby třeba v protokolech souvisejích s kryptografií, což bývá často chyba konceptu, ne kódu jako takového. Samozřejmě i na aplikační úrovni lze něco udělat špatně ("select "+...), ale s použitím běžných knihoven a good practice je to riziko řádově menší.

Ohledně tranzitivních závislostí - to je to, co jsem psal. Ohledně modulů v Java - jo, do té doby, než budu potřebovat, aby spolu ty dvě nekompatibilní verze fungovaly. Tuhle feature Java 9 považuju spíš za kontraproduktivní, bo dává falešný pocit, že tím řeší víc, než ve skutečnosti dokáže. Šedá je teorie, zelený strom života.

Ohledně Qt3 vs Qt5 - nevyřešil, protože to v principu vyřešit nejde. Ten problém existuje na obou úrovních - už v rámci vývoje a případně znovu v rámci distribuce (izolovaný container řeší potenciálně tu druhou část, se všemi zápory, které se tu diskutovaly).

Ty vyšší jazyky nejsou dobrý příklad, drtivá většina knihoven používaných v Javě je napsaná také v Javě (nebo jiném jazyce nad JVM). Navíc není pravda, že by vyšší jazyky abstrahovaly od většiny bezpečnostních chyb, naopak je to jen úzká skupina chyb. Kdyby se dalo bezpečnostním chybám jednoduše vyhnout tak, že se budou používat vyšší jazyky, dávno se v ničem jiném nepíše. Pokud je chyba v protokolu, je potřeba navrhnout nový protokol, který pak aplikace musí použít. Někdy se takové chyby dají obejít úpravou používání protokolu, což obvykle zase musí udělat aplikační programátor. Chyby konceptu jsou velice časté právě v rozhraní knihoven, kdy je možné tu knihovnu používat nebezpečným způsobem – to se opět musí opravit v aplikaci. Netuším, jak jste přišel na to, že u aplikací je to riziko řádově menší.

Pokud by spolu měly dvě nekompatibilní verze knihovny komunikovat, musí to zprostředkovávat přímo aplikace, tudíž to nebude tranzitivní závislost ale přímá závislost, a bude tam samozřejmě jen jedna verze. To samozřejmě neřeší problém, že by jedna z těch knihoven závisela na nějaké staré verzi. Ale tenhle problém má jenom jedno univerzální řešení – vykašlat se na to používat nějaké staré verze a používat všude vždy nejnovější verzi. Pak mají všichni ty závislosti stejné.

Ohledně Qt3 a Qt5 – vývojář to samozřejmě nějak vyřešil (nejspíš tak, že použije jen Qt3 nebo Qt5), protože kdyby to nevyřešil, ta aplikace vůbec nebude existovat a vy jí tudíž nemůžete někam instalovat. Navíc nikdo neodpíská vývoj aplikace jenom proto, že by se mu hodilo použít zároveň Qt3 i Qt5, ale musí si vybrat a použít jenom jednu z nich.