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

[Péťa]

Dobrý den,

Dostal jsem takový domácí úkol, který viipadá následovně:

Kód: [Vybrat]

Vytvořte aplikaci, která vypíše do konzole strukturu nějakého zip souboru, a to takto:

A.zip
   soubor0.txt
   B.zip
      C.zip
      soubor1.txt

V C# se dá rekurzivně soubor A.zip procházet takto:

Kód: [Vybrat]

ZipArchive([b]Stream[/b])
  Inicializuje novou instanci ZipArchive trídy ze zadaného datového proudu.

ZipArchiveEntry ZipArchive.Entries
  Získá kolekci položek, které jsou aktuálne v archivu zip.

[b]Stream [/b]ZipArchiveEntry.open() 
  Otevre položku z archivu zip.

Já se však rozhodl, že raději pužiju Javu, protože je lepší. V Javě ovšem je pouze tato varianta:

Kód: [Vybrat]

ZipFile(File file)

Enumeration<? extends ZipEntry> ZipFile.entries()

InputStream ZipFile.getInputStream(ZipEntry entry)

To samozřejmě nikterak neumožní, získat v A.zip pomocí třídy ZipFile soubor B.zip a ten si opět otevřít a procházet třídou ZipFile, neboť ZipFile umí vzít pouze File, tedy soubor, který musí existovat na disku. Jak jsem dále pátral, v Javě není možné vytvořit virtuální File a provézt tedy celou operaci přes paměť. Není zde tedy jiné možnosti, než B.zip a C.zip rozbalit, uložit separátně na disk, a poté opět otevřít v ZipFile.

Celá záležitost je v případě Javy o to, kulantně řečeno, podivnější, protože jak je známo, výstupní artefakty .jar a .war jsou v podstatě ZIP soubory. Bystrý člověk by tedy očekával, že práce se ZIP soubory by měla být v Javě více než bezproblémová.

Konzultoval jsem to proto s panem Filipem Jirsákem, který je zkušený Javista a Javě se věnoval převážnou část svého života. Podle něj se má věc takto:

Zvolil jste si špatný formát souboru. ZIP není urcený k ukládání na pásku (na rozdíl treba od gzip nebo bzip2), k jeho dekompresi potrebujete náhodný prístup k souboru. Proto to nefunguje se streamem, ale je potreba predat soubor. S Javou to nijak nesouvisí, takhle byste to musel udelat s každou knihovnou v libovolném jazyce.

Z názoru odborníka, pana Jirsáka, jsem však poněkud zmaten. Jednak Java sama produkuje ZIP soubory při sestavování aplikace, do kterých hierarchicky umístí další ZIP soubory v závislostech, které pak obsahují další a další ZIP soubory. Moc tedy nerozumím, proč jsem si vybral špatný formát. Druhý důvod je ten, že podstata Streamu, ve smyslu, jak je používán v .NET nebo v Javě, nemá nutně co dělat s formátem, ve kterém je zdroj uložen - obojí je zkrátka abstraktně představuje tok dat, který může procházet jistou transformací. Domnívám se proto, že sučíp pan Jirsák nemá tak úplně pravdu.

Chtěl bych se proto zeptat vás zkušenější (než já), zdaž-li jde o chibu návrhu standardný knihovny v Java ecčars a pokud ano, zda biste mi to mohli vysvětlit. Myslel jsem si, že Java je velice úspěšná a má za sebou 20 let vývoje a podle některých webů jde dokonce o nejpouživánější jazyk na světě. Používají ho dokonce lidi jako je pan Jirskák, a ti by určitě nedělal v ničem, co by bylo hned ve standardní knihvě Jazyka implementováno poněkud nelogicky.

Děkuji za odpověď.

Péťa.

[Reklama]

[Youda]

Use google, Luke

http://stackoverflow.com/questions/35336870/java-utility-library-for-nested-zip-file-handling

Apropos, Java v zakladmin JDK spoustu veci neumi. A to je dobre, nema smysl cpat do zakladu kazdou kravinu, kterou pouzije jeden clovek ze sta.
Od toho jsou tu externi knihovny, ktere pomoci mavenu seamless zakomponujes do sveho projektu. Sila javy je hlavne v jejim ekosystemu.

Tj. kdyz tvuj projek postavis na mavenu, do pom.xml si pridej zavislost na Apache Commons a opajcuj ten example ze Stac Overflow

[Kamil Podlešák]

Chtěl bych se proto zeptat vás zkušenější (než já), zdaž-li jde o chibu návrhu standardný knihovny v Java ecčars a pokud ano, zda biste mi to mohli vysvětlit.

Ano, jedná se o špatný návrh, pro součásti standardní knihovny z původní verze 1.0 je to poměrně typické.
Většina byla nahrazena něčím lépe navrženým, ale v tomto případě ne.

Jinak samozřejmě existuje ZipInputStream a nad ním se dá rekurzivní procházení postavit. Poměrně jasně si pamatuji že jsem kdysi dělal patchování souborů uvnitř warů uvnitř earu (tj. dvě úrovně zipu a ještě modifikace), streamově... Hledat to nikde v hluboké VCS historii nebudu (nikoho to stejně nězajímá), ale vím že to rozhodně nebyla sranda (teda sranda ve smyslu jednoduché, jinak to naopak sranda docela byla).

Každopádně, standardní řešení je: použít lepší knihovnu. Opensource.



PS: Tak, jeden člověk už se tady vytahoval, vlákno je možné zamknout.

[Péťa]

Use google, Luke

http://stackoverflow.com/questions/35336870/java-utility-library-for-nested-zip-file-handling

Apropos, Java v zakladmin JDK spoustu veci neumi. A to je dobre, nema smysl cpat do zakladu kazdou kravinu, kterou pouzije jeden clovek ze sta.
Od toho jsou tu externi knihovny, ktere pomoci mavenu seamless zakomponujes do sveho projektu. Sila javy je hlavne v jejim ekosystemu.

Tj. kdyz tvuj projek postavis na mavenu, do pom.xml si pridej zavislost na Apache Commons a opajcuj ten example ze Stac Overflow

A proč to teda ten C# umí hned v té základní knihovně a Java to má tak složité? Navíc jsme se ještě před pár dny učili, že nemáme používat standardní Logger, protože spoustu věcí neumí a že prý se stejně používá v praxi Slf4J, log4J nebo Logback a pak je ještě jedna. Já jsem si právěže mislel, že standardní knihovna Jazyka by měla být něco jako základ, ve kterém by všechno mělo fungovat a mělo by to být udělané dobře, protože všichni ostatní programátoři pak na tu budou navazovat. A proč to tam teda není za tolik let opravené nebo nějak vylepšené? V té Javě. Díky

[Péťa]

Chtěl bych se proto zeptat vás zkušenější (než já), zdaž-li jde o chibu návrhu standardný knihovny v Java ecčars a pokud ano, zda biste mi to mohli vysvětlit.

Ano, jedná se o špatný návrh, pro součásti standardní knihovny z původní verze 1.0 je to poměrně typické.
Většina byla nahrazena něčím lépe navrženým, ale v tomto případě ne.

Jinak samozřejmě existuje ZipInputStream a nad ním se dá rekurzivní procházení postavit. Poměrně jasně si pamatuji že jsem kdysi dělal patchování souborů uvnitř warů uvnitř earu (tj. dvě úrovně zipu a ještě modifikace), streamově... Hledat to nikde v hluboké VCS historii nebudu (nikoho to stejně nězajímá), ale vím že to rozhodně nebyla sranda (teda sranda ve smyslu jednoduché, jinak to naopak sranda docela byla).

Každopádně, standardní řešení je: použít lepší knihovnu. Opensource.



PS: Tak, jeden člověk už se tady vytahoval, vlákno je možné zamknout.

Ale já jsem se díval i na ten ZipInputStream a nim to taky nemuze jit. On totiz neumi pro zadnou ZipEntry v zip souboru vytahnout jeji InputStream.

[Reklama]

[Filip Jirsák]

Druhý důvod je ten, že podstata Streamu, ve smyslu, jak je používán v .NET nebo v Javě, nemá nutně co dělat s formátem, ve kterém je zdroj uložen - obojí je zkrátka abstraktně představuje tok dat, který může procházet jistou transformací.

Problém je právě v tom, že je to tok bajtů. Když se podíváte na strukturu formátu ZIP, zjistíte, že přehled toho, co je v ZIPu uloženo, je až na konci souboru (což umožňuje soubor aktualizovat, aniž byste ho musel přepsat celý od začátku). Takže jak byste s tím pracoval, když máte k dispozici jenom tok dat? Začnete číst od začátku, budete přeskakovat v tu chvíli nezajímavá data (protože jim nerozumíte a nevíte, co znamenají), až se konečně dostanete k adresáři na konci souboru, ten přečtete a zjistíte, že požadovaná data byla v tom, co jste zahodil. Ale máte smůlu, je to stream, vrátit se nemůžete.
Poučen tímto nezdarem budete příště stream zpracovávat jinak – při procházení si data budete někam odkládat, když se to nevejde do RAM, odložíte si je na disk. Až se propracujete k závěrečnému adresáři, konečně se dozvíte, co je kde v souboru uložené, vrátíte se k těm datům, co jste si uložil, a konečně je můžete zpracovat.
Trošku divné je, když takhle budete zpracovávat ZIP jako soubor na disku – budete ho načítat jako stream a data si bufferovat do druhého souboru. Proč, když už je jednou v souboru máte? Nehledě na to, že když budete mít velký ZIP a z něj potřebovat vytáhnout malý soubor, můžete klidně skončit na tom, že vám dojde místo na disku.
Když ZIP nedostanete jako stream bajtů, ale jako pole bajtů s náhodným přístupem, můžete s ním pracovat úplně jinak. Prostě si nejdřív přečtete z konce souboru adresář, a podle něj si najdete třeba ten jediný soubor, který chcete rozbalit. Nemusíte nic bufferovat, nemusíte vytvářet zbytečné dočasné soubory.
Java je nízkoúrovňový nástroj, takže vám poskytuje jen ty základní nástroje, abyste mohl něco udělat. Takže pokud chcete rozbalovat ZIP v ZIPu, standardní knihovna Javy vám k tomu dává nástroje, akorát si to budete muset naprogramovat sám. A nebo použijete nějakou knihovnu, která už to má v sobě – třeba zt-zip, zp4j nebo TrueZIP.
Je klidně možné, že C# má už ve standardní knihovně nějakou nadstavbu, která interně řeší to bufferování. Což ale nemění nic na tom, že je to nutné udělat – a můžete jen doufat, že je ta implementace tak chytrá, že zjistí, když je za streamem schovaný soubor, a vykašle se v tom případě na stream a použije náhodný přístup.

[Youda]

Use google, Luke

http://stackoverflow.com/questions/35336870/java-utility-library-for-nested-zip-file-handling

Apropos, Java v zakladmin JDK spoustu veci neumi. A to je dobre, nema smysl cpat do zakladu kazdou kravinu, kterou pouzije jeden clovek ze sta.
Od toho jsou tu externi knihovny, ktere pomoci mavenu seamless zakomponujes do sveho projektu. Sila javy je hlavne v jejim ekosystemu.

Tj. kdyz tvuj projek postavis na mavenu, do pom.xml si pridej zavislost na Apache Commons a opajcuj ten example ze Stac Overflow

A proč to teda ten C# umí hned v té základní knihovně a Java to má tak složité? Navíc jsme se ještě před pár dny učili, že nemáme používat standardní Logger, protože spoustu věcí neumí a že prý se stejně používá v praxi Slf4J, log4J nebo Logback a pak je ještě jedna. Já jsem si právěže mislel, že standardní knihovna Jazyka by měla být něco jako základ, ve kterém by všechno mělo fungovat a mělo by to být udělané dobře, protože všichni ostatní programátoři pak na tu budou navazovat. A proč to tam teda není za tolik let opravené nebo nějak vylepšené? V té Javě. Díky

No opravene/vylepsene to neni asi z toho duvodu, ze to nikdo neudelal. V kazdem frameworku mas nejake diry, nelogicnosti.
Jestli se chces vazneji zabyvat Javou, zacni pouzivat Maven, pak te nezajima, jestli je dana class soucasti oficialni JDK, nebo je to nejake rozsireni od Apache Foundation nebo Google vystavene na Maven Central.
Rozvoj Javy je decentralizovany, neco nacpe Oracle primo do JDK, neco zustane jenom venku na Maven central. Treba Java EE 7 je pomerne tezkopadna, vetsina vyvojaru pouziva konkurencni Spring Framework aniz by to necemu vadilo.

C# ma vsecko primo v base frameworku proto, ze krom MS jenom malokdo externi pro .Net vyviji knihovny. Existuje jakysi pokus NuGet - ale je to v zacatcich a hodne syrove.

[Peťa]

Use google, Luke

http://stackoverflow.com/questions/35336870/java-utility-library-for-nested-zip-file-handling

Apropos, Java v zakladmin JDK spoustu veci neumi. A to je dobre, nema smysl cpat do zakladu kazdou kravinu, kterou pouzije jeden clovek ze sta.
Od toho jsou tu externi knihovny, ktere pomoci mavenu seamless zakomponujes do sveho projektu. Sila javy je hlavne v jejim ekosystemu.

Tj. kdyz tvuj projek postavis na mavenu, do pom.xml si pridej zavislost na Apache Commons a opajcuj ten example ze Stac Overflow

A proč to teda ten C# umí hned v té základní knihovně a Java to má tak složité? Navíc jsme se ještě před pár dny učili, že nemáme používat standardní Logger, protože spoustu věcí neumí a že prý se stejně používá v praxi Slf4J, log4J nebo Logback a pak je ještě jedna. Já jsem si právěže mislel, že standardní knihovna Jazyka by měla být něco jako základ, ve kterém by všechno mělo fungovat a mělo by to být udělané dobře, protože všichni ostatní programátoři pak na tu budou navazovat. A proč to tam teda není za tolik let opravené nebo nějak vylepšené? V té Javě. Díky

No opravene/vylepsene to neni asi z toho duvodu, ze to nikdo neudelal. V kazdem frameworku mas nejake diry, nelogicnosti.
Jestli se chces vazneji zabyvat Javou, zacni pouzivat Maven, pak te nezajima, jestli je dana class soucasti oficialni JDK, nebo je to nejake rozsireni od Apache Foundation nebo Google vystavene na Maven Central.
Rozvoj Javy je decentralizovany, neco nacpe Oracle primo do JDK, neco zustane jenom venku na Maven central. Treba Java EE 7 je pomerne tezkopadna, vetsina vyvojaru pouziva konkurencni Spring Framework aniz by to necemu vadilo.

C# ma vsecko primo v base frameworku proto, ze krom MS jenom malokdo externi pro .Net vyviji knihovny. Existuje jakysi pokus NuGet - ale je to v zacatcich a hodne syrove.

Ale tak prece minymalne ten ZipArchive nikdo nemusel znovu vytvaret v komunitni verzi, kdyz uz dobre funguje v te zakladni. A Logger je v C# taky lepsi nez ten v Jave, nebo ten uz je taky nic moc a vsichni programatori musi v C# pouzivat nejaky externi? A proc je v Jave tolik ruznych externich loggeru, co se pouzivaji, a ne jen jeden? Prece kdyz by byly vsechny napsane poradne a dobre, tak by se nepouzivaly hned 4 najednou, ale nejaky jeden, co bude dobry, ne? Neni to zbytecne umet pracovat se 4 loggery?

[Peťa]

A naco by meli v tom C# teda taky ten Maven, kdyz zadne externi knohovny importovat nemusi, prOtoze uz vsechno ma C# v zakladni verzi? Je to jeste k necemu dobre ten Maven? Nebo to ma Java prave proto, abi se treba daly naimportovat veci, ketere v zakladni Jave budto vubec nejsou nebo tam nejsou udelane moc dobre?

[Filip Jirsák]

Já jsem si právěže mislel, že standardní knihovna Jazyka by měla být něco jako základ, ve kterém by všechno mělo fungovat a mělo by to být udělané dobře, protože všichni ostatní programátoři pak na tu budou navazovat.

Právě proto tam nemůžou být komplexní operace jako rekurzivní rozbalování ZIP souborů, protože ty bude chtít každý udělat trochu jinak. Má tam být právě jen ten základ.

A proč to tam teda není za tolik let opravené nebo nějak vylepšené? V té Javě.

Java drží extrémní politiku zpětné kompatibility – ze standardní knihovny nebylo od verze 1.0 nic odstraněno, včetně věcí, které byly opravené hned v následující verzi (třeba java.util.Date – teď už máme ve standardní knihovně 3. generaci tříd pro práci s datem a časem, ale předchozí generace tam stále zůstávají). Takže některé věci se sice „opravují“, ale takovým způsobem, že se ponechá ta stará „chybná“ verze a vedle ní se přidá nová.
Na tom ZipFile není co opravovat, to, co má dělat, dělá správně. A vylepšovat – proč cpát do standardní knihovny něco, co využije jen málokdo? Ve standardní knihovně má být jen základ.
S tím logováním je to podobné – nějaký základ ve standardní knihovně je, pokud někdo chce něco lepšího, má možnost použít rozšiřující knihovny. Které se mimochodem stále vyvíjí, takže by nebylo rozumné je cpát do standardní knihovny, protože pak byste stejně chtěl používat ty novinky a stejně byste si k aplikaci připojoval externí knihovny. Tohle už bylo s XML knihovnami (ve standardní knihovně byl vložený Xerces a Xalan, které se vedle dál vyvíjely), a byly z toho jen samé problémy a neustále se řešilo, jak z běhového prostředí vyštípat ty staré verze knihoven, které byly součástí JRE, a místo nich použít novější verze. (Tam to navíc bylo dané tím, že autoři Xercesu a Xalanu byli schopni psát C++ v jakémkoli jazyce, takže ty knihovny nebyly se světem Javy moc kompatibilní – a abych jim jen nekřivdil, nutno podotknout, že to bylo už hodně dávno a zdaleka ještě nebylo známo tolik best practices, jak některé věci dělat.)

[Filip Jirsák]

Ale já jsem se díval i na ten ZipInputStream a nim to taky nemuze jit. On totiz neumi pro zadnou ZipEntry v zip souboru vytahnout jeji InputStream.

Ze ZipInputSream nemusíte žádný InputStream vytahovat, ZipInputStream už sám implementuje InputStream.

[Youda]

Use google, Luke

http://stackoverflow.com/questions/35336870/java-utility-library-for-nested-zip-file-handling

Apropos, Java v zakladmin JDK spoustu veci neumi. A to je dobre, nema smysl cpat do zakladu kazdou kravinu, kterou pouzije jeden clovek ze sta.
Od toho jsou tu externi knihovny, ktere pomoci mavenu seamless zakomponujes do sveho projektu. Sila javy je hlavne v jejim ekosystemu.

Tj. kdyz tvuj projek postavis na mavenu, do pom.xml si pridej zavislost na Apache Commons a opajcuj ten example ze Stac Overflow

A proč to teda ten C# umí hned v té základní knihovně a Java to má tak složité? Navíc jsme se ještě před pár dny učili, že nemáme používat standardní Logger, protože spoustu věcí neumí a že prý se stejně používá v praxi Slf4J, log4J nebo Logback a pak je ještě jedna. Já jsem si právěže mislel, že standardní knihovna Jazyka by měla být něco jako základ, ve kterém by všechno mělo fungovat a mělo by to být udělané dobře, protože všichni ostatní programátoři pak na tu budou navazovat. A proč to tam teda není za tolik let opravené nebo nějak vylepšené? V té Javě. Díky

No opravene/vylepsene to neni asi z toho duvodu, ze to nikdo neudelal. V kazdem frameworku mas nejake diry, nelogicnosti.
Jestli se chces vazneji zabyvat Javou, zacni pouzivat Maven, pak te nezajima, jestli je dana class soucasti oficialni JDK, nebo je to nejake rozsireni od Apache Foundation nebo Google vystavene na Maven Central.
Rozvoj Javy je decentralizovany, neco nacpe Oracle primo do JDK, neco zustane jenom venku na Maven central. Treba Java EE 7 je pomerne tezkopadna, vetsina vyvojaru pouziva konkurencni Spring Framework aniz by to necemu vadilo.

C# ma vsecko primo v base frameworku proto, ze krom MS jenom malokdo externi pro .Net vyviji knihovny. Existuje jakysi pokus NuGet - ale je to v zacatcich a hodne syrove.

Ale tak prece minymalne ten ZipArchive nikdo nemusel znovu vytvaret v komunitni verzi, kdyz uz dobre funguje v te zakladni. A Logger je v C# taky lepsi nez ten v Jave, nebo ten uz je taky nic moc a vsichni programatori musi v C# pouzivat nejaky externi? A proc je v Jave tolik ruznych externich loggeru, co se pouzivaji, a ne jen jeden? Prece kdyz by byly vsechny napsane poradne a dobre, tak by se nepouzivaly hned 4 najednou, ale nejaky jeden, co bude dobry, ne? Neni to zbytecne umet pracovat se 4 loggery?

Porad nechapes, ze v Jave je uplne jedno, jesdli dana funkcionalita je soucasti JDK, nebo je externi vystavena v Maven central. Jediny rozdil je v tom, ze v pom.xml (konfigurak mavenu) je zapsany tag <Dependency> ktery odkazuje na prislusnou knihovnu prislusne verze na Maven Central. Pri spusteni maven buildu maven sam knihovny stahne, nastrka je do vysledkeho JAR/WAR.
Kdyz nekdo pozdeji udela lepsi implementaci dane knihovny (napr. Apache CXF nahradila Apache Axis2), no tak se do pom.xml prida odkaz na jinou knihovnu a hotovo.
Neni potreba zasirat JDK prave modnimi funkcemi, po kterych za 5 let nestekne pes, zato budou v JDK strasit naveky.

Zminovany logging je presne ten pripad, puvodni Java Logger je uz davno nahrazeny lepsimi variantami, musi tam ale porad strasit z compatibility duvodu. Dnesni programamator do pom.xml prida:

<!-- https://mvnrepository.com/artifact/org.slf4j/slf4j-api -->
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>1.7.25</version>
</dependency>

A hotovo.
A pokud nekdo udela pozdeji lepsi implementaci, rezidua nebudou v JDK strasit naveky.

Pokud ti mentalni blok nedovoluje pouzivat knihovny mimo base SDK, pak zkratka zustan u C#, tam budes mit lepsi podminky.

[branchman]

Ale já jsem se díval i na ten ZipInputStream a nim to taky nemuze jit. On totiz neumi pro zadnou ZipEntry v zip souboru vytahnout jeji InputStream.

Nehovor ze to nemoze ist, lebo sa najde blbec, ktory nevie, ze to nemoze ist a spravi to.

Ja som riesl podobnu ulohu do vedlajsieho vlakna a aspon na mojom PC mi to funguje. Prikladam riesenie. Sorry za code-style, islo mi len o to to rychlo nabusit.

[Péťa]

Ale já jsem se díval i na ten ZipInputStream a nim to taky nemuze jit. On totiz neumi pro zadnou ZipEntry v zip souboru vytahnout jeji InputStream.

Nehovor ze to nemoze ist, lebo sa najde blbec, ktory nevie, ze to nemoze ist a spravi to.

Ja som riesl podobnu ulohu do vedlajsieho vlakna a aspon na mojom PC mi to funguje. Prikladam riesenie. Sorry za code-style, islo mi len o to to rychlo nabusit.

Dival jsem se na to a moc to nechapu. Proc jsi to udelal tak slozite?

[.]

Už u toho předchozího trolení stačilo napsat mu těch 10 řádků a neřešit nesmysly. Tady diskuze o ničem a řešení se čtyřma třídama.