No mne se nejvice libi nazor na: http://mindprod.com/jgloss/finalize.html
"Some feel finalize should be deprecated, and you should use phantom references instead since they give much better performance. Finalizers interfere with garbage collection. Their main use is debugging. Use them to issue an error message is an object is garbage collected without its close(), dispose(), disconnect()... method being called. " SUN by si IMHO mel zmenit Javadoc dokumentaci k finalize() a vycistit si od toho kod. Koukal jsem do jejich bug databaze, maji par bugu typu "zrusit finalize()" tudle nebo tamhle, ale zadny komplexni bug "zrusit to vsude". 2010/1/28 Filip Jirsák <[email protected]>: > 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 >> >> > >> >> >> > >> > > > -- Ondra Medek
