Swing a uvolnovani Window
Ahoj, narazil jsem na divne chovani Swingu (AWT). Kdyz zmizim JFrame pomoci setVisible(false), tak v pameti zustane viset pres nejaky seznam java.awt.Window.allWindows. Tedy memory leak. Musim volat JFrame.dispose(). Stejne u JDialog. Vzhledem k tomu, ze default close operation u JDialog je HIDE_ON_CLOSE, pak vsechen kod typu MyDialog().setVisible(true); je memory leak, musim delat JDialog d = MyDialog().setVisible(true); d.dispose(); anebo nastavit v MyDialog() construktoru setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE); Tak nevim, je to Java (SUN JRE 1.6) bug? Pokud je to ocekavane chovani, proc neni java.awt.Window.finalize(), ktera by po sobe uklidila? Koukam, ze v Java 5 jeste tato metoda je vyuzita, viz: http://java.sun.com/j2se/1.5.0/docs/api/java/awt/Window.html#finalize%28%29 ale v Java 6 chybi. Dik Ondra Medek
Re: Swing a uvolnovani Window
Zdravím, setVisible(false) okno nezavírá, ale pouze skryje. Pokud chcete okno zavřít, použijte dispose() – přesně jak píšete. Memory leak to je, ale ne na straně Swingu, ale na straně programátora, který okno skrývá když jej ve skutečnosti chce zavřít… S pozdravem Filip Jirsák Dne 26. ledna 2010 15:39 Ondra Medek napsal(a): > Ahoj, > > narazil jsem na divne chovani Swingu (AWT). Kdyz zmizim JFrame pomoci > setVisible(false), tak v pameti zustane viset pres nejaky seznam > java.awt.Window.allWindows. Tedy memory leak. Musim volat > JFrame.dispose(). Stejne u JDialog. Vzhledem k tomu, ze default close > operation u JDialog je HIDE_ON_CLOSE, pak vsechen kod typu > > MyDialog().setVisible(true); > > je memory leak, musim delat > > JDialog d = MyDialog().setVisible(true); > d.dispose(); > > anebo nastavit v MyDialog() construktoru > setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE); > > Tak nevim, je to Java (SUN JRE 1.6) bug? Pokud je to ocekavane > chovani, proc neni java.awt.Window.finalize(), ktera by po sobe > uklidila? Koukam, ze v Java 5 jeste tato metoda je vyuzita, viz: > > http://java.sun.com/j2se/1.5.0/docs/api/java/awt/Window.html#finalize%28%29 > > ale v Java 6 chybi. > > Dik > Ondra Medek >
Re: Swing a uvolnovani Window
Hmm, tak to soudruzi v Sunu zase neco vydumali. Kdyz udelam window.setVisible(false); window = null; Tak objekt v pameti furt visi. To nepovazuji za stastne reseni. Priste abych u kazde tridy louskal manual, jestli nahodou nema specialni metodu, kterou musim volat, nez objekt prestanu pouzivat. Co kdyby neco podobneho bylo treba u kazde JComponent? To bychom se z toho asi pos. 2010/1/26 Filip Jirsák : > Zdravím, > setVisible(false) okno nezavírá, ale pouze skryje. Pokud chcete okno zavřít, > použijte dispose() - přesně jak píšete. Memory leak to je, ale ne na straně > Swingu, ale na straně programátora, který okno skrývá když jej ve > skutečnosti chce zavřít... > > S pozdravem > > Filip Jirsák > > > Dne 26. ledna 2010 15:39 Ondra Medek napsal(a): >> >> Ahoj, >> >> narazil jsem na divne chovani Swingu (AWT). Kdyz zmizim JFrame pomoci >> setVisible(false), tak v pameti zustane viset pres nejaky seznam >> java.awt.Window.allWindows. Tedy memory leak. Musim volat >> JFrame.dispose(). Stejne u JDialog. Vzhledem k tomu, ze default close >> operation u JDialog je HIDE_ON_CLOSE, pak vsechen kod typu >> >> MyDialog().setVisible(true); >> >> je memory leak, musim delat >> >> JDialog d = MyDialog().setVisible(true); >> d.dispose(); >> >> anebo nastavit v MyDialog() construktoru >> setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE); >> >> Tak nevim, je to Java (SUN JRE 1.6) bug? Pokud je to ocekavane >> chovani, proc neni java.awt.Window.finalize(), ktera by po sobe >> uklidila? Koukam, ze v Java 5 jeste tato metoda je vyuzita, viz: >> >> >> http://java.sun.com/j2se/1.5.0/docs/api/java/awt/Window.html#finalize%28%29 >> >> ale v Java 6 chybi. >> >> Dik >> Ondra Medek > > -- Ondra Medek
Re: Swing a uvolnovani Window
> > Tak objekt v pameti furt visi. To nepovazuji za stastne reseni. Priste > abych u kazde tridy louskal manual, jestli nahodou nema specialni > metodu, kterou musim volat, nez objekt prestanu pouzivat. > To ovšem musíte stejně. Na finalizér se nemůžete spoléhat, nikdo vám nezaručí, že vůbec někdy bude zavolán. Uklízet po sobě je slušnost nejen doma v obejváku :-) LT
Re: Swing a uvolnovani Window
K cemu je potom GC a cely ten tezkotonazni aparat? Pro reseni uklidu toho Window IMHO staci WeakReference a propadne finalize() a je to. 2010/1/26 Ladislav Thon : >> Tak objekt v pameti furt visi. To nepovazuji za stastne reseni. Priste >> abych u kazde tridy louskal manual, jestli nahodou nema specialni >> metodu, kterou musim volat, nez objekt prestanu pouzivat. > > To ovšem musíte stejně. Na finalizér se nemůžete spoléhat, nikdo vám > nezaručí, že vůbec někdy bude zavolán. Uklízet po sobě je slušnost nejen > doma v obejváku :-) > > LT > -- Ondra Medek
RE: Swing a uvolnovani Window
Byl bych v těch tvrzení trochu opatrnější, co třeba takové: Thread th = new Thread(new SomeRunnable()); th.start(); th = null; //timhle bych vlakno rozhodne zastavit nechtel On je rozdil v tom, nastavit pointer na null a vykonat na objektu nejakou operaci (třeba to finalize). Jiri Holy -Original Message- From: konference-boun...@java.cz [mailto:konference-boun...@java.cz] On Behalf Of Ondra Medek Sent: Tuesday, January 26, 2010 4:43 PM To: Java Subject: Re: Swing a uvolnovani Window Hmm, tak to soudruzi v Sunu zase neco vydumali. Kdyz udelam window.setVisible(false); window = null; Tak objekt v pameti furt visi. To nepovazuji za stastne reseni. Priste abych u kazde tridy louskal manual, jestli nahodou nema specialni metodu, kterou musim volat, nez objekt prestanu pouzivat. Co kdyby neco podobneho bylo treba u kazde JComponent? To bychom se z toho asi pos. 2010/1/26 Filip Jirsák : > Zdravím, > setVisible(false) okno nezavírá, ale pouze skryje. Pokud chcete okno zavřít, > použijte dispose() - přesně jak píšete. Memory leak to je, ale ne na straně > Swingu, ale na straně programátora, který okno skrývá když jej ve > skutečnosti chce zavřít... > > S pozdravem > > Filip Jirsák > > > Dne 26. ledna 2010 15:39 Ondra Medek napsal(a): >> >> Ahoj, >> >> narazil jsem na divne chovani Swingu (AWT). Kdyz zmizim JFrame pomoci >> setVisible(false), tak v pameti zustane viset pres nejaky seznam >> java.awt.Window.allWindows. Tedy memory leak. Musim volat >> JFrame.dispose(). Stejne u JDialog. Vzhledem k tomu, ze default close >> operation u JDialog je HIDE_ON_CLOSE, pak vsechen kod typu >> >> MyDialog().setVisible(true); >> >> je memory leak, musim delat >> >> JDialog d = MyDialog().setVisible(true); >> d.dispose(); >> >> anebo nastavit v MyDialog() construktoru >> setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE); >> >> Tak nevim, je to Java (SUN JRE 1.6) bug? Pokud je to ocekavane >> chovani, proc neni java.awt.Window.finalize(), ktera by po sobe >> uklidila? Koukam, ze v Java 5 jeste tato metoda je vyuzita, viz: >> >> >> http://java.sun.com/j2se/1.5.0/docs/api/java/awt/Window.html#finalize%28%29 >> >> ale v Java 6 chybi. >> >> Dik >> Ondra Medek > > -- Ondra Medek
Re: Swing a uvolnovani Window
GC slouží k automatické správě _paměti_ a jenom paměti. Byly sice snahy napasovat to i na ostatní zdroje (ve Swingu se nevyznám, ale třeba JDBC je ukázkový příklad), ale ukázalo se, že je s tím víc problémů než užitku (deadlocky v JDBC driverech). Možná, že ve Swingu to lze nějak bezpečně zařídit, ale obecně je spoléhání se na finalizéry při uvolňování zdrojů Špatné (TM). LT 2010/1/26 Ondra Medek > K cemu je potom GC a cely ten tezkotonazni aparat? > > Pro reseni uklidu toho Window IMHO staci WeakReference a propadne > finalize() a je to. > > 2010/1/26 Ladislav Thon : > >> Tak objekt v pameti furt visi. To nepovazuji za stastne reseni. Priste > >> abych u kazde tridy louskal manual, jestli nahodou nema specialni > >> metodu, kterou musim volat, nez objekt prestanu pouzivat. > > > > To ovšem musíte stejně. Na finalizér se nemůžete spoléhat, nikdo vám > > nezaručí, že vůbec někdy bude zavolán. Uklízet po sobě je slušnost nejen > > doma v obejváku :-) > > > > LT > > > > > > -- > Ondra Medek >
Re: Swing a uvolnovani Window
Mam dotaz trochu mimo tema. Zaujala me poznamka o problemech s deadlocky v JDBC driverech v souvislosti s GC. Vim, ze mohu pouzit google, nemate vsak nejaky odkaz, na clanek popisujici tento problem? Diky Honza Ladislav Thon napsal(a): GC slouží k automatické správě _paměti_ a jenom paměti. Byly sice snahy napasovat to i na ostatní zdroje (ve Swingu se nevyznám, ale třeba JDBC je ukázkový příklad), ale ukázalo se, že je s tím víc problémů než užitku (deadlocky v JDBC driverech). Možná, že ve Swingu to lze nějak bezpečně zařídit, ale obecně je spoléhání se na finalizéry při uvolňování zdrojů Špatné (TM). LT 2010/1/26 Ondra Medek mailto:xmed...@gmail.com>> K cemu je potom GC a cely ten tezkotonazni aparat? Pro reseni uklidu toho Window IMHO staci WeakReference a propadne finalize() a je to. 2010/1/26 Ladislav Thon mailto:ladi...@gmail.com>>: >> Tak objekt v pameti furt visi. To nepovazuji za stastne reseni. Priste >> abych u kazde tridy louskal manual, jestli nahodou nema specialni >> metodu, kterou musim volat, nez objekt prestanu pouzivat. > > To ovšem musíte stejně. Na finalizér se nemůžete spoléhat, nikdo vám > nezaručí, že vůbec někdy bude zavolán. Uklízet po sobě je slušnost nejen > doma v obejváku :-) > > LT > -- Ondra Medek
Re: Swing a uvolnovani Window
Ještě bych doplnil: pokud potřebuji použít finalizér, tak správné řešení je použít PhantomReference a speciální vlákno (daemon) které mi provádí úklid. Kamil Podlešák 2010/1/26 Ladislav Thon : > GC slouží k automatické správě _paměti_ a jenom paměti. Byly sice snahy > napasovat to i na ostatní zdroje (ve Swingu se nevyznám, ale třeba JDBC je > ukázkový příklad), ale ukázalo se, že je s tím víc problémů než užitku > (deadlocky v JDBC driverech). > > Možná, že ve Swingu to lze nějak bezpečně zařídit, ale obecně je spoléhání > se na finalizéry při uvolňování zdrojů Špatné (TM). > > LT > > 2010/1/26 Ondra Medek >> >> K cemu je potom GC a cely ten tezkotonazni aparat? >> >> Pro reseni uklidu toho Window IMHO staci WeakReference a propadne >> finalize() a je to. >> >> 2010/1/26 Ladislav Thon : >> >> Tak objekt v pameti furt visi. To nepovazuji za stastne reseni. Priste >> >> abych u kazde tridy louskal manual, jestli nahodou nema specialni >> >> metodu, kterou musim volat, nez objekt prestanu pouzivat. >> > >> > To ovšem musíte stejně. Na finalizér se nemůžete spoléhat, nikdo vám >> > nezaručí, že vůbec někdy bude zavolán. Uklízet po sobě je slušnost nejen >> > doma v obejváku :-) >> > >> > LT >> > >> >> >> >> -- >> Ondra Medek > >
Re: Swing a uvolnovani Window
>Mam dotaz trochu mimo tema. Zaujala me poznamka o problemech s > deadlocky v JDBC driverech v souvislosti s GC. Vim, ze mohu pouzit google, > nemate vsak nejaky odkaz, na clanek popisujici tento problem? > Zkuste narvat do Googlu třeba jdbc deadlock finalize, pěkný popis je kupříkladu tady: http://bugs.mysql.com/bug.php?id=10954. LT
Re: Swing a uvolnovani Window
Tak potom melo to uvolneni zdroju byt jako default v setVisible(false) nebo aspon jako default close operace. Podle mne by to melo byt nastaveno tak, aby se vse uklizelo pri nejjednodusim pouziti. Pokud uklizeni zdrzuje, tak pak se mohou vytvorit metody pro experty, ktere uklizet nebudou. Prave opravuji aplikaci, kde je cca 50 dialogu, 10 frames. Vetsinou se dispose() volalo, nekdy take ne, na default close operaci se vetsinou zapomnelo ... 2010/1/26 Ladislav Thon : > GC slouží k automatické správě _paměti_ a jenom paměti. Byly sice snahy > napasovat to i na ostatní zdroje (ve Swingu se nevyznám, ale třeba JDBC je > ukázkový příklad), ale ukázalo se, že je s tím víc problémů než užitku > (deadlocky v JDBC driverech). > > Možná, že ve Swingu to lze nějak bezpečně zařídit, ale obecně je spoléhání > se na finalizéry při uvolňování zdrojů Špatné (TM). >
Re: Swing a uvolnovani Window
Zdravím, se swingem už jsem dlouho nepracoval, ale jestli se správně pamatuju, tak princip rušení grafických komponent je velice podobný tomu v SWT, takže se můj názor odvíjí od tohoto. Okno, stejně jako většina komponent je nativní systémový resource, tedy něco, co je třeba po sobě manuálně uklidit. Je to podle mě stejný případ jako například inputstream, akorát místo file handlerů vznikají v systému window handlery, tedy něco co se "samo" určitě neuklidí. Spoléhat v tomto případě na finalize() mi přijde asi stejně zcestné jako spoléhat na to, že se sám uklidí file handler po input streamu (to, že opravdu zůstanou viset si asi většina z nás bolestně ověřila). 2 Ondra Medek: To že se občas dispose() nevolalo je spíš problém nedostatečného testování a disciplíny developerů než špatného návrhu Swing API. Navíc mi vzhledem k tomu, že na okně voláte setVisible(false) místo dispose je asi špatné použití metody setVisible, jak už někdo zmínil dříve, protože pokud na té samé instanci komponenty potom zavoláte setVisible(true) měla by se nezměněná objevit, což si dost dobře nedovedu představit, pokud by proběhl úklid resourců. Vytvoření dvou sad metod, jedna pro "běžné developery" a jedna pro experty, se mi zdá jako koncept, který by přinesl spíše chaos než jednoduchost, protože si dost dobře dovedu představit situaci, kdy půlka developerů té samé aplikace používá expertní rozhraní a ta druhá spoléha na to, že se uklízí samo. Výsledkem by byly ty samé chyby, které by se daleko hůř hledaly. Přenášet odpovědnost na GC nedává moc smysl už z podstaty GC, která spočívá v tom, že "si běhá kdy se mu zachce" a tím pádem narozdíl od c++ finalizerů je naprosto nevhodný pro tyto úlohy. Což já osobně považuji za jednu z pro mě nejoblíbenějších specifikací Javy. S pozdravem __ Lukáš Záruba (Lukas Zaruba) Chief Technical Officer MEDIA SOLUTIONS EUROPE Lisabonská 4 Praha 9 190 00 Czech Republic Ondra Medek napsal(a): Tak potom melo to uvolneni zdroju byt jako default v setVisible(false) nebo aspon jako default close operace. Podle mne by to melo byt nastaveno tak, aby se vse uklizelo pri nejjednodusim pouziti. Pokud uklizeni zdrzuje, tak pak se mohou vytvorit metody pro experty, ktere uklizet nebudou. Prave opravuji aplikaci, kde je cca 50 dialogu, 10 frames. Vetsinou se dispose() volalo, nekdy take ne, na default close operaci se vetsinou zapomnelo ... 2010/1/26 Ladislav Thon : GC slouží k automatické správě _paměti_ a jenom paměti. Byly sice snahy napasovat to i na ostatní zdroje (ve Swingu se nevyznám, ale třeba JDBC je ukázkový příklad), ale ukázalo se, že je s tím víc problémů než užitku (deadlocky v JDBC driverech). Možná, že ve Swingu to lze nějak bezpečně zařídit, ale obecně je spoléhání se na finalizéry při uvolňování zdrojů Špatné (TM).
Re: Swing a uvolnovani Window
2010/1/26 Ondra Medek : > Tak potom melo to uvolneni zdroju byt jako default v setVisible(false) Tady si někdo asi dělá legraci, viď? Existuje PLNÝ KRDEL objektů neviditelných. A k tomu se (mimo jiné) právě setVisible(false) používá. Také se to používá při dočasném zobrazení objektu - proč jej znovu vytvářet a zahazovat? Toto prostě nebyl dobrý příklad... > nebo aspon jako default close operace. > > Podle mne by to melo byt nastaveno tak, aby se vse uklizelo pri > nejjednodusim pouziti. Pokud uklizeni zdrzuje, tak pak se mohou > vytvorit metody pro experty, ktere uklizet nebudou. Aha. Pak tedy každý expert musí nastudovat, která metoda mu pod rukou zdroje uklízí a která ne? To mi nepřijde příliš šťastné. Navíc co knihovní funkce? Mají či nemají uklízet? > Prave opravuji aplikaci, kde je cca 50 dialogu, 10 frames. Vetsinou se > dispose() volalo, nekdy take ne, na default close operaci se vetsinou > zapomnelo ... :-) -- Oto 'tapik' Buchta, ta...@buchtovi.cz, http://tapikuv.blogspot.com
Re: Swing a uvolnovani Window
K používání každého objektu si máte přečíst jeho dokumentaci – když to neuděláte, je jen vaše chyba, když ten objekt dělá něco jiného, než byste čekal. Navíc na chování funkce setVisible() není nic zákeřného, ona opravdu dělá přesně to, co má v názvu. To, že vy si myslíte, že když okno nevidíte, tak neexistuje, to není problém té metody, Swingu, ale pouze vašeho pohledu. Ostatně okno také nejprve vytvoříte konstruktorem a pak jej zviditelníte voláním setVisible() – už jen z toho by vás mělo trknout, že existence okna a jeho viditelnost jsou dvě různé věci. GC je od toho, aby z paměti odstranil objekty, které už se nepoužívají. Pořád je ale starostí programátora to, aby zrušil odkazy na objekty, které už nechce používat. Java nemá žádný magický mechanizmus, kterým by určovala, že programátor už asi nechce používat okno, když ho skryl a miliony dalších podobných heuristik, ale používá jednoduché řešení – objekt se používá, dokud na něj jsou odkazy. I v aplikacích s GC jde vyrobit memory leaky, a to právě tak, že programátor zapomene uvolnit některé odkazy i když už objekt nepoužívá. Nesmíte zapomínat na to, že při konstrukci objektu nezískáváte odkaz na objekt jenom vy jako výsledek volání konstruktoru, ale objekt sám má na sebe odkaz přes this. A tenhle odkaz může předat někam dál. Takhle se chovají komponenty, vlákna, spousta posluchačů událostí si drží pevné reference na objekty, na kterých naslouchají… Je zbytečné se nad tím rozčilovat, takhle to prostě je a nedá se říci, zda by bylo lepší řešení bez pevných odkazů – někdy ano, jindy je lepší model s pevnými odkazy. Takže je potřeba si opravdu nastudovat alespoň základy toho, jak s konkrétními objekty zacházet, když je chcete začít používat. finalize() neřeší nic, protože jediné, co je garantováno, je že finalize() nebude na konkrétním objektu spuštěno více než jednou. To ale znamená, že může být spuštěno jednou a nebo také vůbec. S pozdravem Filip Jirsák 2010/1/26 Ondra Medek > K cemu je potom GC a cely ten tezkotonazni aparat? > > Pro reseni uklidu toho Window IMHO staci WeakReference a propadne > finalize() a je to. > > 2010/1/26 Ladislav Thon : > >> Tak objekt v pameti furt visi. To nepovazuji za stastne reseni. Priste > >> abych u kazde tridy louskal manual, jestli nahodou nema specialni > >> metodu, kterou musim volat, nez objekt prestanu pouzivat. > > > > To ovšem musíte stejně. Na finalizér se nemůžete spoléhat, nikdo vám > > nezaručí, že vůbec někdy bude zavolán. Uklízet po sobě je slušnost nejen > > doma v obejváku :-) > > > > LT > > > > > > -- > Ondra Medek >
Re: Swing a uvolnovani Window
> Aha. Pak tedy každý expert musí nastudovat, která metoda mu pod rukou > zdroje uklízí a která ne? To mi nepřijde příliš šťastné. Lepsi kdyz to studuje expert, nez amater. Nakonec expert by to mozna napsal lepe v C++. Proto je Java tak oblibena, ze se v ni chyb da delat mene a jsou snadneji odhalitelne. Situace je jina, pokud mate aplikaci, kterou od zacatku do konce vyvijite sam nebo aspon nad vyvojem mate dohled. V beznem zivote ale na vas spadne existujici aplikace (nebo lepe nekolik aplikaci), na ktere se behem radu let vystridala rada lidi s ruznym stupnem znalosti Javy, Swingu (a pripadne hafo dalsich knihoven). Pak jste vdecny za co nejjednodussi programove konstrukce, ve kterych nelze udelat chyba.
Re: Swing a uvolnovani Window
Přičemž k těm nejjednodušším programovým konstrukcím patří třeba to, že každá funkce dělá právě jednu činnost, a to tu, která je zdokumentovaná. Takže například metoda setVisible(boolean) nastavuje viditelnost objektu, a nesnaží se uhodnou, jestli si programátor náhodou neplete viditelnost s existencí. Existují programovací jazyky, které se jednoduchosti použití snaží docílit tím, že před programátorem spoustu věcí skrývají a snaží se je nějak vyřešit za něj, ale Java je přesný opak takových jazyků. Java je assembler nad JVM a její jednoduchost spočívá v tom, že stojí na několika základních jednoduchých principech. To ale nemá nic společného s tím, že by se překladač nebo běhové prostředí nějak pokoušely uhodnout, co programátor chtěl – právě naopak. Nenechte se mást tím, že má Java GC, který něco dělá zdánlivě automaticky a bez dohledu uživatele. Za prvé jsou pravidla pro programování s tímto typem GC možná jednodušší, než pravidla pro programování s explicitní alokací paměti, za druhé ta automatika není mezi uživatelským programem a JVM, ale mezi JVM a systémem. Je to asi na stejné úrovni, jako je pro nativní programy přerovnávání instrukcí procesorem – tedy daleko za hranicí toho, co běžně potřebujete. Pro běžné případy ale úplně stačí vědět, že dokud existují na objekt tvrdé odkazy, je objekt dostupný a zabírá místo v paměti. Jinak je myslím zbytečné dál toto téma rozebírat, buďte rád, že jste se něco o správě odkazů v Javě dozvěděl už teď při takovéhle jednoduché záležitosti – třeba při vícevláknovém programování je někdy potřeba vědět o vzniku a zániku referencí mnohem podrobněji, protože můžete třeba snadno pracovat s objektem, který ještě nebyl zcela vytvořen. Filip Jirsák Lepsi kdyz to studuje expert, nez amater. Nakonec expert by to mozna > napsal lepe v C++. Proto je Java tak oblibena, ze se v ni chyb da > delat mene a jsou snadneji odhalitelne. > > Situace je jina, pokud mate aplikaci, kterou od zacatku do konce > vyvijite sam nebo aspon nad vyvojem mate dohled. V beznem zivote ale > na vas spadne existujici aplikace (nebo lepe nekolik aplikaci), na > ktere se behem radu let vystridala rada lidi s ruznym stupnem znalosti > Javy, Swingu (a pripadne hafo dalsich knihoven). Pak jste vdecny za co > nejjednodussi programove konstrukce, ve kterych nelze udelat chyba.
Re: Swing a uvolnovani Window
2010/1/26 Ondra Medek : >> Aha. Pak tedy každý expert musí nastudovat, která metoda mu pod rukou >> zdroje uklízí a která ne? To mi nepřijde příliš šťastné. > > Lepsi kdyz to studuje expert, nez amater. Nakonec expert by to mozna > napsal lepe v C++. Proto je Java tak oblibena, ze se v ni chyb da > delat mene a jsou snadneji odhalitelne. On by to expert mozna prece jen napsal v Jave ;-) > Situace je jina, pokud mate aplikaci, kterou od zacatku do konce > vyvijite sam nebo aspon nad vyvojem mate dohled. V beznem zivote ale > na vas spadne existujici aplikace (nebo lepe nekolik aplikaci), na > ktere se behem radu let vystridala rada lidi s ruznym stupnem znalosti > Javy, Swingu (a pripadne hafo dalsich knihoven). Pak jste vdecny za co > nejjednodussi programove konstrukce, ve kterych nelze udelat chyba. Naprosto s vami souhlasim. Jenomze tech konstrukci, ktere Swing pouziva, opravdu mnoho neni. A je vzdy na aktualnim vedoucim projektu, aby mel zaruceno, ze kdyz uz tam nejake prase programatora ma, tak ze jsou nastavene mechanismy tak, aby se podobna zverstva (zavirani oken pomoci setVisible(false)) proste nedely. Na zaver debaty, ve ktere asi uz nema smysl pokracovat, par poznamek: - Java je prave proto tak uzasna, ze se nesnazi delat za lidi to, co by meli delat sami. Proto dela GC prave a pouze to, co dela. To, ze nektere knihovny jsou hodne automagicke, je jejich problem, nikoli jazyka. Mozna prave proto se v konferenci permanentne objevuji dotazy na Hibernate, asi nejautomagictejsi knihovnu napsanou v Jave. O pouziti JDBC se objevi jeden dotaz rok... - kdyz chce nekdo pouzivat knihovnu, mel by si byt setsakra jist, ze spravne pochopil jeji principy. To, ze by si precetl jeji dokumentaci, ho stejne nikdo nedonuti (aneb Pratchettovske "Chtel bych mit jeden bronzovy naramek za kazdeho uzivatele naseho megalitickeho pocitace, ktery se ani neunavoval precist si manual!") - kdyz se predava aplikace, mela by fungovat rozumna komunikace mezi byvalym a novym [programatorem, vedoucim, testerem,,,]. Muzeme odchazet z firmy zneucteni, zneuziti a odkopnuti, ale nase stavovska cest by nam mela velet predat vse v co nejlepsim poradku. Ten, kdo prijde po mne, za to prece nemuze. -- Oto 'tapik' Buchta, ta...@buchtovi.cz, http://tapikuv.blogspot.com
Re: Swing a uvolnovani Window
To je naozaj problem v tom, ze niekto si neprecita poriadne dokumentaciu, alebo niekto pred nim si neprecita poriadne dokumentaciu a problem sa tiahne. Ved podla mna uz prvy priklad prace so Swingom, kde si len zobrazite prazdne okno, vas donuti pouzit EXIT_ON_CLOSE. Inak zistite, ze po desiatich spusteniach mate desat skrytych, ale nedisposenutych okien a teda desat neviditelnych spustenych aplikacii. (U mna na cviceniach sa to prejavilo evidentne: ludom zacal zdochynat Eclipse :-)). Ale chapem, ze casto clovek vpadne do technologie a neexistuje priestor / cas / prilezitost na tutorialove upozornenia. Automagicke disposovanie okien je presne taky pripad ako Connectiony, ResultSety a Statementy, a presne taky isty priklad ako zatvaranie java.io.OutputStreamov ci Writerov. Nie je to teda ziadna rarita. Ak vznikaju problemy, tak presne preto, ze vznika dojem, ze Java upratuje vsetko, vzdy a vsade, a dokonca aj tam, kde je to vyslovne v zodpovednosti programatora. On 26. 1. 2010 21:26, Ondra Medek wrote: Aha. Pak tedy každý expert musí nastudovat, která metoda mu pod rukou zdroje uklízí a která ne? To mi nepřijde příliš šťastné. Lepsi kdyz to studuje expert, nez amater. Nakonec expert by to mozna napsal lepe v C++. Proto je Java tak oblibena, ze se v ni chyb da delat mene a jsou snadneji odhalitelne. Situace je jina, pokud mate aplikaci, kterou od zacatku do konce vyvijite sam nebo aspon nad vyvojem mate dohled. V beznem zivote ale na vas spadne existujici aplikace (nebo lepe nekolik aplikaci), na ktere se behem radu let vystridala rada lidi s ruznym stupnem znalosti Javy, Swingu (a pripadne hafo dalsich knihoven). Pak jste vdecny za co nejjednodussi programove konstrukce, ve kterych nelze udelat chyba.
Re: Swing a uvolnovani Window
Dne 26. ledna 2010 17:28 Kamil Podlesak napsal(a): > Ještě bych doplnil: pokud potřebuji použít finalizér, tak správné > řešení je použít PhantomReference a speciální vlákno (daemon) které mi > provádí úklid. e.p.: Pouzil uz z vas nekdo PhantomReference? -- Oto 'tapik' Buchta, ta...@buchtovi.cz, http://tapikuv.blogspot.com
Re: Swing a uvolnovani Window
V navaznosti na tuto diskuzi bych rad poznamenal, ze jednim z navrhu na
vylepseni Javy je Automatic Resource Management. Misto
static String readFirstLineFromFile(String path) throws IOException {
BufferedReader br = new BufferedReader(new FileReader(path));
try {
return br.readLine();
} finally {
br.close();
}
}
bychom pak mohli psat
static String readFirstLineFromFile2(String path) throws IOException {
try (BufferedReader br = new BufferedReader(new FileReader(path)) {
return br.readLine();
}
}
K zavreni streamu br dojde automaticky po opusteni bloku try. Mimochodem,
C# to ma.
Z.T.
--
Zdenek Tronicek
FIT CTU in Prague
Filip Jirsák napsal(a):
> Přičemž k těm nejjednodušším programovým konstrukcím patří třeba to, že
> každá funkce dělá právě jednu činnost, a to tu, která je zdokumentovaná.
> Takže například metoda setVisible(boolean) nastavuje viditelnost objektu,
> a
> nesnaží se uhodnou, jestli si programátor náhodou neplete viditelnost s
> existencí.
>
> Existují programovací jazyky, které se jednoduchosti použití snaží docílit
> tím, že před programátorem spoustu věcí skrývají a snaží se je nějak
> vyřešit
> za něj, ale Java je přesný opak takových jazyků. Java je assembler nad JVM
> a
> její jednoduchost spočívá v tom, že stojí na několika základních
> jednoduchých principech. To ale nemá nic společného s tím, že by se
> překladač nebo běhové prostředí nějak pokoušely uhodnout, co programátor
> chtěl – právě naopak. Nenechte se mást tím, že má Java GC, který něco dělá
> zdánlivě automaticky a bez dohledu uživatele. Za prvé jsou pravidla pro
> programování s tímto typem GC možná jednodušší, než pravidla pro
> programování s explicitní alokací paměti, za druhé ta automatika není mezi
> uživatelským programem a JVM, ale mezi JVM a systémem. Je to asi na stejné
> úrovni, jako je pro nativní programy přerovnávání instrukcí procesorem –
> tedy daleko za hranicí toho, co běžně potřebujete. Pro běžné případy ale
> úplně stačí vědět, že dokud existují na objekt tvrdé odkazy, je objekt
> dostupný a zabírá místo v paměti.
>
> Jinak je myslím zbytečné dál toto téma rozebírat, buďte rád, že jste se
> něco
> o správě odkazů v Javě dozvěděl už teď při takovéhle jednoduché
> záležitosti
> – třeba při vícevláknovém programování je někdy potřeba vědět o vzniku a
> zániku referencí mnohem podrobněji, protože můžete třeba snadno pracovat s
> objektem, který ještě nebyl zcela vytvořen.
>
> Filip Jirsák
>
> Lepsi kdyz to studuje expert, nez amater. Nakonec expert by to mozna
>> napsal lepe v C++. Proto je Java tak oblibena, ze se v ni chyb da
>> delat mene a jsou snadneji odhalitelne.
>>
>> Situace je jina, pokud mate aplikaci, kterou od zacatku do konce
>> vyvijite sam nebo aspon nad vyvojem mate dohled. V beznem zivote ale
>> na vas spadne existujici aplikace (nebo lepe nekolik aplikaci), na
>> ktere se behem radu let vystridala rada lidi s ruznym stupnem znalosti
>> Javy, Swingu (a pripadne hafo dalsich knihoven). Pak jste vdecny za co
>> nejjednodussi programove konstrukce, ve kterych nelze udelat chyba.
>
Re: Swing a uvolnovani Window
> V navaznosti na tuto diskuzi bych rad poznamenal, ze jednim z navrhu na > vylepseni Javy je Automatic Resource Management. Je to jeden z akceptovaných návrhů Project Coin: http://wikis.sun.com/display/ProjectCoin/2009ProposalsTOC, takže by se to mělo objevit v Javě 7. A já volám, když už nebyly vyslyšeny moje modlitby stran lexikálních uzávěrů: sláva! Sláva! Mimochodem, C# má spoustu věcí, které Javě IMHO chybí. A Groovy ostatně taky. To jen když už jsme se pustili do těžce off-topic témat :-) LT
Re: Swing a uvolnovani Window
Tak to byly Tvoje modlitby :-). A ja si porad lamal hlavu, co primelo
Marka Reinholda, aby zmenil nazor na closures a zahrnul je do JDK 7.
Po jeho oznameni na Devoxxu je velmi pravdepodobne, ze closures budou. Jen
se zatim nevi, jak budou vypadat.
Mozna takto:
#int(String) strLen = #(String s) {
if (s == null) return -1;
return s.length();
};
nebo takto:
#(String: int) strLen = #(String s: int length) label:{
if (s == null) { length =-1; break label; }
length = s.length();
};
nebo treba i takto:
#(String: int) strLen = #int(String s) length: {
if (s == null) break length =-1;
length = s.length();
};
a nebo uplne jinak.
Z.T.
--
Zdenek Tronicek
FIT CTU in Prague
Ladislav Thon napsal(a):
>> V navaznosti na tuto diskuzi bych rad poznamenal, ze jednim z navrhu na
vylepseni Javy je Automatic Resource Management.
> Je to jeden z akceptovaných návrhů Project Coin:
> http://wikis.sun.com/display/ProjectCoin/2009ProposalsTOC, takže by se
to
> mělo objevit v Javě 7. A já volám, když už nebyly vyslyšeny moje
modlitby
> stran lexikálních uzávěrů: sláva! Sláva!
> Mimochodem, C# má spoustu věcí, které Javě IMHO chybí. A Groovy ostatně
taky. To jen když už jsme se pustili do těžce off-topic témat :-) LT
