Java a C# - porovnání práce se Zip souborem

Inkvizitor

Re:Java a C# - porovnání práce se Zip souborem
« Odpověď #30 kdy: 29. 04. 2017, 07:36:30 »
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.

Trošku off topic, než se do sebe zase pustíte - tohle fakt znamená, že Java dokáže číst data ze zip souboru, který nemá konec? To by se mohlo hodit.


Re:Java a C# - porovnání práce se Zip souborem
« Odpověď #31 kdy: 29. 04. 2017, 09:04:24 »
Trošku off topic, než se do sebe zase pustíte - tohle fakt znamená, že Java dokáže číst data ze zip souboru, který nemá konec? To by se mohlo hodit.
Ano, znamená. Ale také to znamená, že ten soubor je poškozený, a že tím pádem můžete přečíst něco, co v tom ZIPu vůbec není. Je to podobné, jako když si u souborového systému omylem smažete hlavičku – existují nástroje, které se pokusí z něj zachránit data, ale musíte počítat s tím, že dostanete spoustu souborů na jedné hromadě, kterou si pak budete muset ručně roztřídit na to, co je správné a platné, a na smetí, které se tam připletlo omylem.

Inkvizitor

Re:Java a C# - porovnání práce se Zip souborem
« Odpověď #32 kdy: 29. 04. 2017, 09:19:11 »
Trošku off topic, než se do sebe zase pustíte - tohle fakt znamená, že Java dokáže číst data ze zip souboru, který nemá konec? To by se mohlo hodit.
Ano, znamená. Ale také to znamená, že ten soubor je poškozený, a že tím pádem můžete přečíst něco, co v tom ZIPu vůbec není. Je to podobné, jako když si u souborového systému omylem smažete hlavičku – existují nástroje, které se pokusí z něj zachránit data, ale musíte počítat s tím, že dostanete spoustu souborů na jedné hromadě, kterou si pak budete muset ručně roztřídit na to, co je správné a platné, a na smetí, které se tam připletlo omylem.

Díky za odpověď, tohle jsem pochopil. Nicméně v typickém případě se zip dělá sekvenčně a nemodifikuje, nebo ne?

Re:Java a C# - porovnání práce se Zip souborem
« Odpověď #33 kdy: 29. 04. 2017, 09:41:29 »
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.
Názorná ukázka toho, že čím méně toho člověk ví, tím méně informací má o tom, co všechno neví – a má pak pocit, že rozumí skoro všemu. Vaše poučování o tom, jak by něco mělo být správně architektonicky navržené, je zábavné – když si uvědomíme, že neumíte naprogramovat triviální domácí úkol, a neumíte vlastně ani správně číst a psát. Navíc celý balíček java.util.zip byl do Javy přidán v JDK 1.1, která byla vydána před dvaceti lety – takže jdete trošku s křížkem po funuse.

Podstatně blíže abstraktnímu pojetí streamu je totiž v podstatě Iterator. To je správně abstraktně napsaný Stream.
To, že vy máte jakousi mlhavou představu, co by měl dělat váš stream, vůbec neznamená, že jsou ostatní povinni to slovo používat stejně. Java prostě na začátku zavedla pro proud bajtů označení „stream“, protože se to hodilo a slovo „stream“ v té době bylo ve světě programování volné.

Nikdo netvrdí, že něco, co je Stream nad zip souborem, musí procházet i smazané soubory,.
Netvrdím to ani já. Kdybyste si přečetl pořádně, co jsem napsal, dozvěděl byste se, že ZipInputStream, tak, jak je implementován v JRE, nutně prochází i smazané soubory nebo staré verze souborů. A že se tak nutně musí chovat každá implementace, která bude zip soubor načítat z proudu bajtů a nebude ho někde bufferovat. Plyne to z toho, jakou má zip formát strukturu – že „hlavička“ souboru s informacemi, kde co v souboru je, je uložená až na konci souboru.

Asi vám formát toho souboru připadá hloupý, protože abyste s tím souborem mohl rozumně pracovat, musíte mít k jeho obsahu náhodný přístup. Jenže ten souborový formát vznikl už v době pevných disků, které náhodný přístup umožňují – a tahle struktura formátu má tu obrovskou výhodu, že můžete ze zip souboru získat jeden soubor, aniž byste musel procházet vše, co je před ním. A zároveň to umožňuje vytvořit zip soubor na jediný průchod.

ValidZipInputStream by byl taky stream a vracel by klidně jen validní soubory podle té vaší zip složky.
Akorát že takový stream by si nutně musel někam bufferovat načítaná data. Což není nic, co by mělo být ve standardní knihovně, protože je to velmi implementačně závislé. Někdy budete vědět, že stačí bufferovat do RAM, někdy budete vědět, že je potřeba použít disk, někdy budete vědět, že můžete disků použít víc, někdy, že stačí bufferovat jen některé položky. To si můžete implementovat v nějaké knihovně, ale nemá to co dělat v nízkoúrovňové základní knihovně.

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ě?
Máte zmatek v základních objektech, o kterých se tu bavíme. Souborový systém odpovídá zip souboru, jednotlivé soubory na tom souborovém systému odpovídají jednotlivým souborům v zipu. Ostatně existují různé nástroje, které se umí k zip souboru chovat, jako by to byl souborový systém. Streamy nad soubory v Javě (FileInputStream, FileOutputStream) operují nad jednotlivými soubory, ZipInputStream ale operuje nad celým zip souborem, tedy nad kolekcí souborů – tedy by to odpovídalo streamu nad celým souborovým systémem. Kdybyste implementoval nějaký třeba (pro jednoduchost) FATInputStream, který by měl na vstupu proud bajtů, měl byste s tím úplně stejný problém – musel byste data bufferovat (a to by vám u FAT stačilo bufferovat jen hlavičku, protože u FAT je na začátku diskového oddílu).

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.
Děkuji za péči. Souhlasím s tím, že jeden z nás v tom má velký guláš. A myslím si, že je to ten, kdo neumí naprogramovat takovou trivialitu, jako je rekurzivní výpis seznamu souborů v zip souboru.

Pokud to, co tvrdí trochu pomýlený pan Jirsák o ZipInputStream, je pravda, totiž že čte i nevalidní soubory v zip archivu
Já jsem se díval do zdrojáku té třídy a na specifikaci zip formátu. Odkud své informace čerpáte vy? Navíc já jsem nepsal, že čte nevalidní soubory v zip archivu – napsal jsem, že čte i položky, které mohly být později upravené nebo smazané.

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.
Nemyslím si, že by vás pustili k něčemu, kde by mohly vzniknout škody v řádech milionů dolarů. A lidé, kteří umí aspoň trochu programovat, nebudou používat FileInputStream, který je k ničemu, ale použijí ZipFile nebo rovnou nějakou knihovnu. A taky si zjistí něco o formátu zip a ověří si, jestli je v souladu zadání a to, co chtějí použít při implementaci.

Re:Java a C# - porovnání práce se Zip souborem
« Odpověď #34 kdy: 29. 04. 2017, 09:53:34 »
Nicméně v typickém případě se zip dělá sekvenčně a nemodifikuje, nebo ne?
Pravděpodobně ano. Nicméně vždycky je možnost, že ten zip někdo dodatečně upraví (dělal jsem to mnohokrát), taky je možné, že se někomu z důvodu snazší implementace hodí vytvořit ho „modifikovaný“ rovnou. A pak je tu samozřejmě možnost, že někdo vytvoří nějaký záškodnický plně validní zip záměrně.

Což je potřeba brát docela vážně, když uvážíte, že moderní souborové formáty kancelářských balíků (OpenDocument od OpenOffice.org a Office Open XML od Microsoftu) jsou zip archivy, zip archivy jsou třeba i binární balíčky Java programů. Takže když to rozbalíte špatně, můžete dostat jiný dokument nebo jiný program. Všechny zmíněné formáty umožňují dokument/balíček i podepsat, ale podepisuje se jen vnitřek zipu. Takže některým chybným implementacím rozbalení zipu (které by ignorovaly „hlavičku“ souboru) by bylo možné podstrčit dokumenty nebo balíčky, které by byly validním zipem, ta chybná implementace by je bez problémů rozbalila, seděly by všechny podpisy – akorát by tam bylo něco jiného, než kdybyste ten zip rozbalil správně.


tnr

Re:Java a C# - porovnání práce se Zip souborem
« Odpověď #35 kdy: 29. 04. 2017, 09:59:22 »
Paneboze, tak toto je novy level, porovnavat jazyky podlepodpory archaickeho archivu.

C# implementace si to nacte do bufferu v pameti, coz je zrovna tak spatne reseni, co kdyz budu po tcp socketu chtit nacist 100 gb zip stream?))) Hlavne uplne umele vykonstruovany problem, od kdy je podpora zip v standardni knihovne ukazka kvality jazyka? Co  jazyky,co ji nemaji zadnou?

Péťa

Re:Java a C# - porovnání práce se Zip souborem
« Odpověď #36 kdy: 29. 04. 2017, 12:03:51 »
Pane Jirsáku, ja vždy na root.cz obdivuji vaši vytrvalost a vervu s jakou dokazujete, že jste dost podivný člověk. Kdo jiný by taky na Twitteru likoval Merkelovou jako největšího státníka v Evropě.

Takže si to vezměme hezky popořádku. Stream je v Javě implementován dost blbě a nikdo se nad tím očividně řádně nezamyslel. Ve světě OOP mi opravdu označení pro Stream - tedy obecně proud něčeho - nepříjde vůbec nějak volné, ale naprosto jednoznačně se odkazující ke specifikaci, nad jakým typem dat to má vlastně proud má být. Viz Java 8 - Streamy.

Takže takový příklad, který vám poslouží jako taková berlička, pane Jirsáku, abyste konečně vymanil z te nevědomosti a pochopil, že bufferování nehraje roli při rozhodování, zda-li něco je stream nebo není:

Kód: [Vybrat]
class CommandInputStream extends BufferedInputStream<Command,KeyStroke> { ... }
class CompositeCommand extends Command { // ctrl+alt+del ? }

class ZipInputStream extends BufferedInputStream<ZipEntry,Byte>

Vám totiž nejde do hlavinky, že i input stream, který musí načíst nejprve celý vstupní stream, je rovněž stream. Takže ne, není pravda, co tvrdíte, že každá implementace ZipStreamu musí nutně na výstup posílat rovněž nevalidní soubory. Takto se to rozhodli udělat v Javě a je to samozřejmě špatně, protože to neuvedli v dokumentaci.

Dále, je-li v nějaké knihovně třída pro práci se zip archivy, pojmenujme ji teď lépe ZipArchive, očekává se od ní, že uživatelům umožní rozbalit soubor, který chtějí. Když nějaký uživatel bude používat tuto třídu ZipArchive, očekává, že bude správně fungovat, ne, že fungovat nebude. Je takový problém, aby se v případě, že dochází paměť, začalo prostě bufferovat na disk? Nic jiného k zajištění správné funkce ani není možné, takže proč vy vlastně tvrdíte, že je to problematické a že si to musí každý naimplementovat sám podle svých potřeb? Implementace ZipArchive je naprosto jednoznačně daná.

Pane Jirsáku, vemte si někdy taky dovolenou, oddechněte si, sportujte, nechoďte tolik na sluníčko a bude to zase fajn.

Re:Java a C# - porovnání práce se Zip souborem
« Odpověď #37 kdy: 29. 04. 2017, 12:36:12 »
Pane Jirsáku, ja vždy na root.cz obdivuji vaši vytrvalost a vervu s jakou dokazujete, že jste dost podivný člověk. Kdo jiný by taky na Twitteru likoval Merkelovou jako největšího státníka v Evropě.
Pan Jirsák je jistě podivný člověk a je možné že má i podivné politické názory, ale na druhou stranu dokáže bez zbytečného rozčilování argumentovat a psát věci které jsou v podstatě pravdivé a mají hlavu a patu, maximálně jsou někdy trochu offtopic nebo to jsou osobní názory (které jsou z principu subjektivní). Ještě jsem ale neviděl, že by napsal něco skutečně špatně.

Tradičním oponentem je pak někdo, kdo ho z nějakého důvodů nesnáší tolik, že prostě vidí jenom rudou mlhu.
... bufferování nehraje roli při rozhodování, zda-li něco je stream nebo není...
...Vám totiž nejde do hlavinky, že i input stream, který musí načíst nejprve celý vstupní stream, je rovněž stream....
...Takže ne, není pravda, co tvrdíte, že každá implementace ZipStreamu musí nutně na výstup posílat rovněž nevalidní soubory....
Hezky vyvrácené, bohužel obě dvě tvrzení jsou naprosto vymyšlené, Filip Jirsák nic takového netvrdil.

Je takový problém, aby se v případě, že dochází paměť, začalo prostě bufferovat na disk?
Jenom pro pořádek: ano, je. Nebudu vysvětlovat proč - koho to zajímá tak si to dá jako domácí úkol.

Vlastně když nad tím tak přemýšlím - tohle je taková krásná otázka na pohovor. Jaké jsou problémy té jdk implementace a API, jak by to vypadalo lépe, a jakým špatným nápadům se vyhnout. Minimálně se tím roztřídí lidi na nudné praktiky, tlučhuby a ty co skutečně dokáží někam dohlédnout. Navrhnout dobře API a vůbec knihovnu je prostě něco, co každý nezvládne na první pokud (koneckonců, příkladem je jak Java, tak C# nebo třeba Python)

Pane Jirsáku, vemte si někdy taky dovolenou, oddechněte si, sportujte, nechoďte tolik na sluníčko a bude to zase fajn.
To je asi to nejrozumnější co tady padlo. Ale platí to pro tebe, a případně další individua s pěnou u huby.

Otázka do pléna: proč někteří tolik nesnáší Filipa Jirsáka, že se sebe dělají takové kretény?

Tnr

Re:Java a C# - porovnání práce se Zip souborem
« Odpověď #38 kdy: 29. 04. 2017, 12:51:46 »
Pane Jirsáku, ja vždy na root.cz obdivuji vaši vytrvalost a vervu s jakou dokazujete, že jste dost podivný člověk. Kdo jiný by taky na Twitteru likoval Merkelovou jako největšího státníka v Evropě.

Takže si to vezměme hezky popořádku. Stream je v Javě implementován dost blbě a nikdo se nad tím očividně řádně nezamyslel. Ve světě OOP mi opravdu označení pro Stream - tedy obecně proud něčeho - nepříjde vůbec nějak volné, ale naprosto jednoznačně se odkazující ke specifikaci, nad jakým typem dat to má vlastně proud má být. Viz Java 8 - Streamy.

Takže takový příklad, který vám poslouží jako taková berlička, pane Jirsáku, abyste konečně vymanil z te nevědomosti a pochopil, že bufferování nehraje roli při rozhodování, zda-li něco je stream nebo není:

Kód: [Vybrat]
class CommandInputStream extends BufferedInputStream<Command,KeyStroke> { ... }
class CompositeCommand extends Command { // ctrl+alt+del ? }

class ZipInputStream extends BufferedInputStream<ZipEntry,Byte>

Vám totiž nejde do hlavinky, že i input stream, který musí načíst nejprve celý vstupní stream, je rovněž stream. Takže ne, není pravda, co tvrdíte, že každá implementace ZipStreamu musí nutně na výstup posílat rovněž nevalidní soubory. Takto se to rozhodli udělat v Javě a je to samozřejmě špatně, protože to neuvedli v dokumentaci.

Dále, je-li v nějaké knihovně třída pro práci se zip archivy, pojmenujme ji teď lépe ZipArchive, očekává se od ní, že uživatelům umožní rozbalit soubor, který chtějí. Když nějaký uživatel bude používat tuto třídu ZipArchive, očekává, že bude správně fungovat, ne, že fungovat nebude. Je takový problém, aby se v případě, že dochází paměť, začalo prostě bufferovat na disk? Nic jiného k zajištění správné funkce ani není možné, takže proč vy vlastně tvrdíte, že je to problematické a že si to musí každý naimplementovat sám podle svých potřeb? Implementace ZipArchive je naprosto jednoznačně daná.

Pane Jirsáku, vemte si někdy taky dovolenou, oddechněte si, sportujte, nechoďte tolik na sluníčko a bude to zase fajn.


Nevim, jake ma Filip Jirsak nazory na politiku, pokud ma Merkel za dobrou politicku, tak se asi neshodneme, nicmene to:
* je uplne jedno
* nesouvisi s Javou
* nemeni nic na faktu, ze Jirsak je jeden z mala slusne a vecne diskutujicich v tehle zumpe, ktera si v nicem nezada s vykvety na novinkach

Zpatky k Jave. Evidentne v tom mas hokej, pokud michas Streams API a IO streamy. Oboji je jasne definovane, oboji k necemu uplne jinemu a hlavne to spoku vubec nesouvisi.

IO Stream, ktery prvne nacte vsechna data do pameti a jeste mozna neco zapise na disk, je opravdu skvela defininice streamu a uzasne pouzitelne pro proudove zpracovani zprav, DoS funkci programator dostane jako bonus...

Tvuj problem je, ze chces produove zpravovavat format, ktery na to neni urceny a nadavas Javu, ze nedela spatny workaround, ktery by byl skodlivy, jen pro tve pohodli.

Péťa

Re:Java a C# - porovnání práce se Zip souborem
« Odpověď #39 kdy: 29. 04. 2017, 13:10:58 »
Hokej v tom máš ty. Já jsem tady mluvil o Streamech abstraktních, řekl jsem, že Java 8 Stream api tuto abstraktnost cti ale InputStream a Jirsák ji nectí. To je jedna věc.

Druhá věc je, že nechci proudově zpracovávat formát, který proudem není, jen tvrdím, že je možné ho proudově zpracovat, ikdyž to znamená, že se musí nejprve celý načíst. To, že se musí celý načíst, neznamená, že to nemůže být proud.

Dokonce jsem jak pro debily uvedl příklad, že běžně existují streamy, které musí bufferovat, aby vytvořily správnou transformaci na výstupu. Ale je to marné, je to marné, je to marné.

Re:Java a C# - porovnání práce se Zip souborem
« Odpověď #40 kdy: 29. 04. 2017, 13:31:38 »
Takže si to vezměme hezky popořádku. Stream je v Javě implementován dost blbě a nikdo se nad tím očividně řádně nezamyslel. Ve světě OOP mi opravdu označení pro Stream - tedy obecně proud něčeho - nepříjde vůbec nějak volné, ale naprosto jednoznačně se odkazující ke specifikaci, nad jakým typem dat to má vlastně proud má být. Viz Java 8 - Streamy.
Vezměte to popořádku. Nejprve získejte nějaké znalosti, a pak o tom něco pište. InputStream a OutpuStream jsou v Javě od verze 1.0, tedy od roku 1996. Stream API bylo přidáno do Javy ve verzi 8, tedy v roce 2014. Spletl jste se jenom o 18 let.

Takže takový příklad, který vám poslouží jako taková berlička, pane Jirsáku, abyste konečně vymanil z te nevědomosti a pochopil, že bufferování nehraje roli při rozhodování, zda-li něco je stream nebo není:
Kde jsem psal, že bufferování hraje roli při rozhodování, že je něco stream? Aha, nikde, to vy jenom neumíte číst. Zkusím vám to vysvětlit ještě jednou. Některé formáty dat jsou uspořádané tak, že k interpretaci dat, které jsou v proudu dat dříve, potřebujete informaci, která je v proudu dat až později. Pokud máte náhodný přístup ke všem datům, není to žádný problém – prostě si nejprve přečtete ten konec, zjistíte potřebné informace a na jejich základě pak přečtete začátek. Pokud ale ta data dostáváte od začátku do konce, tenhle postup použít nemůžete – když dostanete ta data na začátku, ještě nevíte, co s nimi máte dělat, musíte si je odložit někam stranou (do nějakého bufferu) a později se k nim vrátit.

Zkusím vám to uvést na takovém příkladu, jde jen o sčítání a odčítání malých čísel, to už jste snad ve škole bral. My jsme zvyklí používat infixovou notaci, kdy jsou tyto matematické operátory uvedené mezi operandy, třeba 5 + 3 - 7. Zkuste si, jak byste naprogramoval výpočet, kdybyste měl na vstupu stream operandů a operátorů zapsaných v tomhle pořadí (tedy byste měl stream 5, +, 3, -, 7). Dá se to udělat tak, že nemusíte nic bufferovat, pouze si budete pamatovat aktuální mezivýsledek a prováděnou operaci (což by se také dalo chápat jako buffer, ale nebudu vám to komplikovat).

Pro zápis matematických operací se dá ale použít také třeba postfixová notace, nebo-li reverzní polská notace (RPN). V té se zapisují nejprve operandy a teprve za nimi je operátor. Ten výše uvedený příklad můžete v RPN zapsal jako 5 3 7 - +6. (Ty dva zápisy nejsou ekvivalentní, tohle odpovídá v infixové notaci zápisu 5 + (3 - 7). Ale pro ulehčení jsem zvolil jen sčítání a odčítání, které mají stejnou prioritu, tudíž ani v infixové notaci nejsou závorky potřeba.) Opět máte na vstupu stream operandů a operátorů, tentokrát tedy 5, 3, 7, -, +. Dokážete naprogramovat výpočet jenom na základě toho streamu, aniž byste si musel bufferovat přicházející hodnoty, tj. ukládat si je do nějakého zásobníku?

Vám totiž nejde do hlavinky, že i input stream, který musí načíst nejprve celý vstupní stream, je rovněž stream.
Napsal jsem někde něco, z čeho by toto plynulo? Aha, nenapsal, to jenom vy neumíte číst. Napsal jsem, že aby bylo možné s tím zip archivem pracovat správně, musíte stejně celý ten stream přečíst a nabufferovat si ho, tj. zapsat někam, kde k němu budete mít přístup pro náhodné čtení – třeba do RAM nebo na disk.

A v tom je ten problém, který vy stále nechápete. Protože to bufferování může být operace velmi náročná na zdroje. Ano, nějaká knihovna to před vámi může skrýt, aby to mohli používat i takoví neumětelové, jako vy. Jenže to vám bude fungovat jen v jednoduchých případech. Když vám pak někdo pošle 100 GB zip („prosím vypal mi tenhle Blue-ray“) a ta vaše knihovna se ho pokusí celý načíst do paměti, nedopadne to moc slavně.

Takže ne, není pravda, co tvrdíte, že každá implementace ZipStreamu musí nutně na výstup posílat rovněž nevalidní soubory.
Což jsem opět nikde netvrdil, to jenom vy neumíte číst. Já jsem napsal, že pokud nemám přístup k datům zipu pro náhodné čtení (tj. mohu si kdykoli zvolit, kterou část zipu přečtu), ale mám k dispozici jenom proud bajtů, musím si ten proud bajtů odkládat někam, kde budu mít ten náhodný přístup – protože jedině tak dokážu zajistit, že ten příchozí zip archiv zpracuju správně.

Takto se to rozhodli udělat v Javě a je to samozřejmě špatně, protože to neuvedli v dokumentaci.
Jak už jsem psal, ta třída je velmi stará a dokumentace ještě pochází z doby, kdy programátoři rozuměli tomu, co dělají. Programátor, který zná formát zip archivu a přečte si tu dokumentaci, pochopí, jaká to má úskalí. Dneska už programují lidé jako vy, takže by v té dokumentaci mělo být uvedeno, ať se té třídě obloukem vyhnou lidé, kteří o formátu zip nic nevědí.

Dále, je-li v nějaké knihovně třída pro práci se zip archivy, pojmenujme ji teď lépe ZipArchive, očekává se od ní, že uživatelům umožní rozbalit soubor, který chtějí. Když nějaký uživatel bude používat tuto třídu ZipArchive, očekává, že bude správně fungovat, ne, že fungovat nebude.
Což je přesně to, co dělá třída java.util.zip.ZipFile. Nebo vy snad máte nějaký příklad, kdy funguje špatně?

Je takový problém, aby se v případě, že dochází paměť, začalo prostě bufferovat na disk?
Ano, je to problém třeba v případě, kdy nemáte k dispozici disk, na který můžete zapisovat. Nebo v případě, kdy na disku nemáte volné místo.

Nic jiného k zajištění správné funkce ani není možné
Ale je to možné. Víte, občas někdo přijde s takovou školní úlohou, že má vypsat názvy souborů v tom zipu. Proč by pak rozbaloval ty soubory na disk, když je vůbec nepotřebuje? Když vám pošlu po síti 100 GB zip s úkolem, že máte vypsat názvy souborů v něm obsažených, a vy máte aplikaci spuštěnou na bezdiskovém počítači se 4 GB RAM, je to bez problémů splnitelný úkol. Akorát to musí naprogramovat někdo, kdo aspoň trochu ví, o co jde.

takže proč vy vlastně tvrdíte, že je to problematické a že si to musí každý naimplementovat sám podle svých potřeb?
Protože o té problematice alespoň něco malilinko vím. Vám, který o tom nevíte vůbec nic, se to samozřejmě všechno zdá snadné. Jenom se to naučit a mohl byste to naimplementovat.

Pane Jirsáku, vemte si někdy taky dovolenou, oddechněte si, sportujte, nechoďte tolik na sluníčko a bude to zase fajn.
Mám pro vás špatnou zprávu. Pokud byste se někdy skutečně naučil alespoň základy programování, pochopíte, jak hloupé byly vaše komentáře v této diskusi. Teď to vědět nemůžete, protože když nevíte vůbec nic, nemáte ani znalosti na to, abyste pochopil, jak málo toho víte.

Já jsem tady mluvil o Streamech abstraktních, řekl jsem, že Java 8 Stream api tuto abstraktnost cti ale InputStream a Jirsák ji nectí. To je jedna věc.
Už jsem vám vysvětloval, že IO streamy v Javě tento název ctít nemohou, když vznikly asi tak 15 let před tímto názvem.

Druhá věc je, že nechci proudově zpracovávat formát, který proudem není, jen tvrdím, že je možné ho proudově zpracovat, ikdyž to znamená, že se musí nejprve celý načíst. To, že se musí celý načíst, neznamená, že to nemůže být proud.
Akorát když ten proud načtete do paměti s náhodným přístupem a pracujete pak s tou pamětí, nepracujete už s proudem dat, ale s pamětí s náhodným přístupem. Ten postup „načíst do paměti“ není možné provést vždy – proud je potenciálně nekonečný, a to se vám do paměti fakt nevejde.

Ale je to marné, je to marné, je to marné.
Není to marné. Naučili se to jiní před vámi, není důvod, proč byste se nenaučil programovat i vy. Není to těžké.

Nemo7

Re:Java a C# - porovnání práce se Zip souborem
« Odpověď #41 kdy: 29. 04. 2017, 13:55:20 »
Není to marné. Naučili se to jiní před vámi, není důvod, proč byste se nenaučil programovat i vy. Není to těžké.
Já tedy nevím, nechci nikomu brát iluze o snadnosti programování. Programováním se živím už 10 let, mám tento obor i vystudovaný. S přestávkami programuji od třinácti let, od dob osmibitů. Postupem doby si začínám říkat, že programovat v podstatě pořádně vůbec neumím (tj. vím že nic nevím). Existuje tam TOLIK záludností, jazyků a stylů programování a dost těžké teorie... Samozřejmě jde o to, co pro koho znamená umět programovat. Pro mě například to znamená vytvoření vlastního interpretru, rozumět pořádně paralelnímu programování atp.

Re:Java a C# - porovnání práce se Zip souborem
« Odpověď #42 kdy: 29. 04. 2017, 14:16:54 »
Já tedy nevím, nechci nikomu brát iluze o snadnosti programování. Programováním se živím už 10 let, mám tento obor i vystudovaný. S přestávkami programuji od třinácti let, od dob osmibitů. Postupem doby si začínám říkat, že programovat v podstatě pořádně vůbec neumím (tj. vím že nic nevím). Existuje tam TOLIK záludností, jazyků a stylů programování a dost těžké teorie... Samozřejmě jde o to, co pro koho znamená umět programovat. Pro mě například to znamená vytvoření vlastního interpretru, rozumět pořádně paralelnímu programování atp.
Souhlasím, nemyslel jsem to tak, že je lehké naprogramovat cokoli. Chtěl jsem tím říct, že naprogramovat jednoduché věci není složité. Nejtěžší na tom je poznat, kdy nejde o jednoduchou věc :-)

Nemo7

Re:Java a C# - porovnání práce se Zip souborem
« Odpověď #43 kdy: 29. 04. 2017, 14:55:25 »
Souhlasím, nemyslel jsem to tak, že je lehké naprogramovat cokoli. Chtěl jsem tím říct, že naprogramovat jednoduché věci není složité. Nejtěžší na tom je poznat, kdy nejde o jednoduchou věc :-)
Souhlasím, ale jak nám říkal jeden vyučující - musíte chápat i složitější věci, aby se vám zdály ty snadné skutečně snadné. Jak je vidět z průběhu tohoto tématu, někteří se ještě nedostali ani do této fáze. ;)

Re:Java a C# - porovnání práce se Zip souborem
« Odpověď #44 kdy: 29. 04. 2017, 15:17:43 »
Souhlasím, ale jak nám říkal jeden vyučující - musíte chápat i složitější věci, aby se vám zdály ty snadné skutečně snadné. Jak je vidět z průběhu tohoto tématu, někteří se ještě nedostali ani do této fáze. ;)
A nebo nevědět nic, pak se zdá snadné všechno :-)