Tam je totiž základní kravina v tom, že je tam vůbec nějaká třída umožňující procházet zip soubor implementovaná jako nějaký potomek InputStream, protože to má být spíše potomek Iterator. Toť věc první. Druhý problém, podstatně základnější, tam je v tom, že InputStream není napsán dostatečně abstraktně. Proto vůbec vznikla taková kravina, jako je FilteredInputStream.
InputStream by se totiž měl správně jmenovat ByteInputStream. Je to totiž, stejně jako v C#, proud nad typem byte. Správně, abstraktně implementovaná třída Stream, by měla být generická, s možnosti vybrat si, nad jakou jednotkou to stream vlastně je. Protože proud může být nad byte, nad soubory, nad ip pakety, nad tenisovými míčky nebo nad molekulami vody.
Takže tam je základní problém už v architektuře a C# to pak z Javy blbě okopíroval, takže svůj Stream impplementuje stejně blbě.
Podstatně blíže abstraktnímu pojetí streamu je totiž v podstatě Iterator. To je správně abstraktně napsaný Stream.
A teď k vám, pane Jirskáku. Nikdo netvrdí, že něco, co je Stream nad zip souborem, musí procházet i smazané soubory,. Stream je abstraktní věc. ValidZipInputStream by byl taky stream a vracel by klidně jen validní soubory podle té vaší zip složky. Na disku máte taky data fyzicky zapsány různě napřeskáčku a některé z nich jsou smazané, připadá vám však ale, že nad soubory pak fungují streamy nějak blbě? Takže si v tom udělajte pořádek pane Jirskáku, zamyslete, co jsou to vlastně streamy, máte už na to věk.
A teď zpátky od pana Jirsáka k Javě. Pokud to, co tvrdí trochu pomýlený pan Jirsák o ZipInputStream, je pravda, totiž že čte i nevalidní soubory v zip archivu a není to ani uvedeno v dokumentaci, tak je to, obávám se, ještě větší sračka, než si všichni mysleli, a nechci ani domýšlet, kolik tento paskvil, kterých je v Javě povícero, způsobil, za dobu své existence, škod v řádech milionů dolarů, a to na jen nejrůznějších chybách v produkci.
69 Odpovědí
11511 Zhlédnutí