K metodě finalize() - jediný smysl má tehdy, pokud si člověk sám řídí Garbage collector. Vím minimálně o jednom případě, kdy jsem tak musel činit, neb knihovna, kterou jsem musel použít, byla tak příšerně napsaná, že to ani jinak nešlo. Z licenčních důvodů jsem do ní nemohl zasáhnout a tak jsem jenom naimplementoval jednoduchý wrapper kolem jejich dao objektu, který jsem zaregistroval pro použití místo jejich. Po skončení určité části knihovna zavolala GC a to byla jediná chvíle, kdy jsem se dostal k informaci, že je komunikace právě v tomto stavu. K tomu samozřejmě mají vlastní GC a mluví o tom jako o úžasné vlastnosti, že si sami prý qůli rychlosti řídí GC :-( No blivajz.
Dne 28. ledna 2010 13:24 Filip Jirsák <[email protected]> napsal(a): > Přesně tak jsem to myslel - ne vyhodit výjimku ať ji zpracuje někdo jiný, > ale zpracovat ji stejným způsobem, jako výjimky obvykle zpracováváte, s > přihlédnutím k tomu, že se pohybujete na tenkém ledě metody finalize(). > > Filip Jirsák > > > Dne 28. ledna 2010 12:50 Kamil Podlesak <[email protected]> > napsal(a): >> >> Tady bych opravil: výjimku ve finalize() zapsat do logu, vyhodit ji >> nemá moc smysl (to je právě jeden z problémů finalize: co se stane >> když vyletí výjimka?) >> >> Jinak tuto praktiku vřele doporučuji, samozřejmě je pak nutné nechat >> nějak automaticky sledovat (grepovat) aplikační log na produkci a >> nalezené chyby opravovat. >> Spoléhat na programátorskou disciplinu je _velmi_ deprecated :-) >> >> Kamil Podlešák >> >> 2010/1/28 Filip Jirsák <[email protected]>: >> > Ještě doplním, že může být vhodné tu pojistku doplnit assertem, který >> > upozorní na to, že někdo někde tu úklidovou metodu zavolat zapomněl. >> > Záleží >> > pak na kontextu, jestli tohle stačí, nebo jestli je k tomu potřeba si >> > táhnout nějakou další informaci - typicky v konstruktoru si (pod >> > assertem) >> > vytvořit výjimku, uložit si ji, při zavolání close() ji vymazat a ve >> > finalize() otestovat její přítomnost, a pokud výjimka existuje, vyhodit >> > jí. >> > >> > S pozdravem >> > >> > Filip Jirsák >> > >> > -- >> > [email protected] >> > >> > >> > Dne 28. ledna 2010 11:44 Zdenek Tronicek <[email protected]> >> > napsal(a): >> >> >> >> Aplikacni programator udela nejlepe, kdyz na finalize() zapomene a >> >> misto >> >> nej bude pouzivat metodu pro uklid a try + finally: >> >> >> >> InputStream is = ... >> >> try { >> >> ... >> >> } finally { >> >> is.close(); >> >> } >> >> >> >> Pokud jde o to, zda ma finalize nekdy smysl, tak ano: muze to byt >> >> pojistka >> >> pro pripad, ze programator zapomnel zavolat uklidovou metodu. >> >> Programator >> >> by na to ovsem nemel spolehat a mel by se snazit, aby kazdy objekt po >> >> sobe >> >> uklidil. >> >> Jinak ten clanek, ktery uvadis, je z roku 98. Takze to asi nebude >> >> nejvhodnejsi zdroj. >> >> >> >> Z.T. >> >> -- >> >> Zdenek Tronicek >> >> FIT CTU in Prague >> >> >> >> >> >> Ondra Medek napsal(a): >> >> > Ahoj, >> >> > >> >> > navazuji tak trochu na predchozi thread. Jsem ted zmaten, jesli ma >> >> > Object.finalize() smysl nebo by mel byt @Deprecated. Pokud ma smysl, >> >> > tak kdy ho pouzit? >> >> > >> >> > V JDK 1.6 JavaDoc dokumentaci >> >> > >> >> > >> >> > http://java.sun.com/javase/6/docs/api/java/lang/Object.html#finalize%28%29 >> >> > stoji: >> >> > >> >> > "For example, the finalize method for an object that represents an >> >> > input/output connection might perform explicit I/O transactions to >> >> > break the connection before the object is permanently discarded." >> >> > >> >> > Clanek ja Javaworld >> >> > http://www.javaworld.com/javaworld/jw-06-1998/jw-06-techniques.html >> >> > tez radi ve finalize() uvolnovat systemove zdroje, ale pouze jako >> >> > "fallback mechanism". (Coz mi presne sedi pro ten java.awt.Window >> >> > problem). >> >> > >> >> > Progrepoval jsem JDK 1.6 zdrojaky a SUN se k finalize() asi stavi >> >> > ambivalentne: nekde ho pouziva, nekde ne. Priklady pouziti: >> >> > java.util.zip.ZipFile - zavira IO stream >> >> > java.io.FileInputStream + java.io.FileOutputStream : zaviraji file >> >> > descriptory >> >> > ... a dalsi >> >> > >> >> > Nejvice je onen ambivalentni pristup videt na ImageInputStreamImpl a >> >> > FileImageOutputStream z baliku javax.imageio.stream: >> >> > ImageInputStreamImpl ma finalize(), ktere v podstate jen nastavi >> >> > priznak isClosed = true >> >> > FileImageOutputStream je potomek ImageInputStreamImpl a prepisuje >> >> > finalize(), ve kterem nedela nic. >> >> > >> >> > Dale jsem nasel treba zakomentovany finalize(), ktery puvodne >> >> > zavitral >> >> > IO stream, v com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl >> >> > s >> >> > poznamkou, ze "It affects the performance greatly in multi-thread >> >> > environment. ". Tedy ZipFile vesele IO stream zavira ve finalize(), >> >> > kdezto CoreDocumentImpl to ma zakomentovane. >> >> > >> >> > Diky >> >> > Ondra Medek >> >> > >> >> >> > >> > > > -- Oto 'tapik' Buchta, [email protected], http://tapikuv.blogspot.com
