Kdy pouzit Object.finalize()?
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
Re: Kdy pouzit Object.finalize()?
Zdravím, Efektivně by se měl považovat za deprecated. Problém je v tom, že vlastně netušíme jaký je stav aplikace v okamžiku volání finalize. Nevíme v jakém jsme právě vlákně, nevíme jaké máme k dispozici prostředky. Může se docela klidně stát, že něco co potřebujeme k uklizení je již uvolněno a finalizováno - nebo je právě uvolňováno. Nevíme zda je bezpečné zamknout sdílené objekty nebo není - čeká na nás GC nebo ne? A tak dále, a tak dále... V jednoduchých případech nic z toho nevadí; bohužel, jednoduchých případů moc není. Jak jsem již napsal v předchozí diskusi: pokud potřebuji po nějakém objektu uklízet, místo finalize() je lepší používat PhantomReference a uklízecího démona, který vybírá události o uvolnění objektu (z ReferenceQueue) a pak provede úklid. Má to dvě hlavní výhody: - uvolněný objekt již skutečně neexistuje - na rozdíl od finalize(), kdy je v jakémsi nedefinovaném stavu (očistec ?) - uklízecí démon může brát v úvahu aplikační stav - zda je již aplikace plně inicializovaná a nakonfigurovaná, nebo naopak zda probíhá shutdown, atd - uklízecí démon má k dispozici všechno co celá aplikace - databáze, komunikace s okolím, může klidně na všechno toto čekat... Snad jsem to napsal trochu srozumitelně. Kamil Podlešák 2010/1/28 Ondra Medek xmed...@gmail.com: 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
Re: Kdy pouzit Object.finalize()?
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
Re: Kdy pouzit Object.finalize()?
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
--
fi...@jirsak.org
Dne 28. ledna 2010 11:44 Zdenek Tronicek troni...@fit.cvut.cz 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
Re: Kdy pouzit Object.finalize()?
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 filip.jir...@gmail.com:
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
--
fi...@jirsak.org
Dne 28. ledna 2010 11:44 Zdenek Tronicek troni...@fit.cvut.cz 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
Re: Swing a uvolnovani Window
Je tam extra sekcia Responding to Window Closing Events :-) By default, when the user closes a frame onscreen, the frame is hidden. Although invisible, the frame still exists and the program can make it visible again. If you want different behavior, then you need to either register a window listener that handles window-closing events, or you need to specify default close behavior using the |setDefaultCloseOperation| method. You can even do both. Pod tym traktat ku konstantnam. A hej, suhlasim, priklady su casto neuplne, napr. JDBC je povestne zlymi prikladmi, ktore malokedy zatvoria vsetky connectiony, resultsety a statementy poriadne. Ludia to potom kopiruju rovno do kodu, a potom to robi podivnosti. On 27. 1. 2010 16:34, Ondra Medek wrote: Ale chapem, ze casto clovek vpadne do technologie a neexistuje priestor / cas / prilezitost na tutorialove upozornenia. Zadne tutorialove upozornenia nevidim: http://java.sun.com/docs/books/tutorial/uiswing/components/dialog.html http://java.sun.com/docs/books/tutorial/uiswing/components/frame.html I nektere priklady jinde na webu jsou spatne: http://www.java2s.com/Code/Java/Swing-JFC/Createsimpleaboutdialog.htm A JInternalFrame ma default close operation jako DISPOSE, aby to nebylo tak jednoduche :-) Nechci zacit flame, ale treba C# to ma vyresene lepe. Jako nektere dalsi veci, jak uz zde bylo zmineno.
Re: Kdy pouzit Object.finalize()?
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 kamil.podle...@gmail.comnapsal(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 filip.jir...@gmail.com:
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
--
fi...@jirsak.org
Dne 28. ledna 2010 11:44 Zdenek Tronicek troni...@fit.cvut.cz
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
Re: Kdy pouzit Object.finalize()?
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 filip.jir...@gmail.com:
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 kamil.podle...@gmail.com
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 filip.jir...@gmail.com:
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
--
fi...@jirsak.org
Dne 28. ledna 2010 11:44 Zdenek Tronicek troni...@fit.cvut.cz
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
Re: Kdy pouzit Object.finalize()?
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 filip.jir...@gmail.com 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 kamil.podle...@gmail.com
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 filip.jir...@gmail.com:
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
--
fi...@jirsak.org
Dne 28. ledna 2010 11:44 Zdenek Tronicek troni...@fit.cvut.cz
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, ta...@buchtovi.cz, http://tapikuv.blogspot.com
Re: Kdy pouzit Object.finalize()?
Dne 28. ledna 2010 13:59 Zdenek Tronicek troni...@fit.cvut.cz napsal(a): Dost odstrasujici pripad. Volani System.gc() by mel kazdy vedouci projektu zakazat. Krome nekolika No mne to povídej. Dva mesice jsem s nima resil presne specifikovane reprodukovatelne chovani, na ktere vygenerovali deset rad a zadna nezafungovala, az jsem zacal dekompilovat jejich kod... Nejvetsi sranda vzdycky je, kdyz treba ma firma dva modely HW, jeden pro ameriku a jeden pro evropu a kazdy se chova jinak. Do API pridaji kod, ktery umi pracovat s atributem, ktery umi pouze evropsky model. Kdyz proti evropskemu modelu clovek pouzije americkou verzi API, tak sice metoda projde, ale nic nenastavi. Kdyz clovek zavola evropskou verzi API, dostane vyjimku Unknown command :-( Po dekompilaci pak zjistis, ze onu hlasku posila uz onen evropsky model, ktery jako jediny to ma umet. A podpora je samozrejme jenom v Americe a oni nemaji k dispozici evropsky model, takze jim to taky hlasi stejnou vyjimku a vubec se nedivi. Grrr! Nakonec jsem se quli tomu naucil ruby. -- Oto 'tapik' Buchta, ta...@buchtovi.cz, http://tapikuv.blogspot.com
Re: Kdy pouzit Object.finalize()?
Ad po zavolani System.gc se vzdy spusti Full GC) S tim bych si dovolil
polemizovat. V materiálech SCJP uvádí, že vynutit GC nelze, resp není to
garantováno. Sice o to můžeme požádat právě voláním tohoto příkazu, ale
GC se může rozhodnout, že nic neudělá. Záleží tak silně na implementaci
JVM (jak to mají napsané).
Arny
Zdenek Tronicek wrote:
Dost odstrasujici pripad.
Volani System.gc() by mel kazdy vedouci projektu zakazat. Krome nekolika
specialnich situaci, jako jsou performance testy, stejne k nicemu neni a
velmi casto nadela vice skody nez uzitku (po zavolani System.gc se vzdy
spusti Full GC a dochazi k presunu objektu z young generace do tenured).
Z.T.
--
Zdenek Tronicek
FIT CTU in Prague
Oto Buchta napsal(a):
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 filip.jir...@gmail.com 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 kamil.podle...@gmail.com
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 filip.jir...@gmail.com:
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
--
fi...@jirsak.org
Dne 28. ledna 2010 11:44 Zdenek Tronicek troni...@fit.cvut.cz
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
Re: Re: Kdy pouzit Object.finalize()?
To je sice pravda, ale asi jen ve specifikaci... Minimalne Suni JVM pri
System.gc zahaji Full GC (prakticky overeno na 1.6 na Win i Linux). Konkretne
jsem na to narazil pri exportu reportu pres JasperReports, ktery kdesi v nitru
vola System.gc :( JVM pak pri generovani reportu v cca 20 soubezne pustenych
threadech totalne vyradila cely slavny dual quad-core stroj a v GC logu bezel
jeden Full GC za druhym. Po disablovani System.gc problem samozrejme zmizel.
=== http://java.sun.com/docs/hotspot/gc1.4.2/ (u novejsich JVM to je stejne)
===
Another way applications can interact with garbage collection is by invoking
full garbage collections explicitly, such as through the System.gc() call.
These calls force major collection, and inhibit scalability on large systems.
The performance impact of explicit garbage collections can be measured by
disabling explicit garbage collections using the flag -XX:+DisableExplicitGC.
===
Od te doby bez -XX:+DisableExplicitGC nic provozuji :) Osobne bych System.gc z
API uplne vyradil, jelikoz jde proti logice GC, bohuzel je to tam od 1.0. No
alespon deprecated kdyby to bylo...
Honza
Původní zpráva
Od: Arnošt Havelka have...@igsoft.cz
Předmět: Re: Kdy pouzit Object.finalize()?
Datum: 28.1.2010 19:17:18
Ad po zavolani System.gc se vzdy spusti Full GC) S tim bych si dovolil
polemizovat. V materiálech SCJP uvádí, že vynutit GC nelze, resp není to
garantováno. Sice o to můžeme požádat právě voláním tohoto příkazu, ale
GC se může rozhodnout, že nic neudělá. Záleží tak silně na implementaci
JVM (jak to mají napsané).
Arny
Zdenek Tronicek wrote:
Dost odstrasujici pripad.
Volani System.gc() by mel kazdy vedouci projektu zakazat. Krome nekolika
specialnich situaci, jako jsou performance testy, stejne k nicemu neni a
velmi casto nadela vice skody nez uzitku (po zavolani System.gc se vzdy
spusti Full GC a dochazi k presunu objektu z young generace do tenured).
Z.T.
--
Zdenek Tronicek
FIT CTU in Prague
Oto Buchta napsal(a):
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 filip.jir...@gmail.com 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 kamil.podle...@gmail.com
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 filip.jir...@gmail.com:
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
--
fi...@jirsak.org
Dne 28. ledna 2010 11:44 Zdenek Tronicek troni...@fit.cvut.cz
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
Re: Re: Kdy pouzit Object.finalize()?
Mate pravdu oba. Ja psal o Sun JVM, protoze jine temer nepouzivam. Nicmene
ve specifikaci je, ze JVM muze volani System.gc() ignorovat.
Z.T.
--
Zdenek Tronicek
FIT CTU in Prague
Jan Moravec napsal(a):
To je sice pravda, ale asi jen ve specifikaci... Minimalne Suni JVM pri
System.gc zahaji Full GC (prakticky overeno na 1.6 na Win i Linux).
Konkretne jsem na to narazil pri exportu reportu pres JasperReports, ktery
kdesi v nitru vola System.gc :( JVM pak pri generovani reportu v cca 20
soubezne pustenych threadech totalne vyradila cely slavny dual quad-core
stroj a v GC logu bezel jeden Full GC za druhym. Po disablovani System.gc
problem samozrejme zmizel.
=== http://java.sun.com/docs/hotspot/gc1.4.2/ (u novejsich JVM to je
stejne) ===
Another way applications can interact with garbage collection is by
invoking full garbage collections explicitly, such as through the
System.gc() call. These calls force major collection, and inhibit
scalability on large systems. The performance impact of explicit garbage
collections can be measured by disabling explicit garbage collections
using the flag -XX:+DisableExplicitGC.
===
Od te doby bez -XX:+DisableExplicitGC nic provozuji :) Osobne bych
System.gc z API uplne vyradil, jelikoz jde proti logice GC, bohuzel je to
tam od 1.0. No alespon deprecated kdyby to bylo...
Honza
Původní zpráva
Od: Arnošt Havelka have...@igsoft.cz
Předmět: Re: Kdy pouzit Object.finalize()?
Datum: 28.1.2010 19:17:18
Ad po zavolani System.gc se vzdy spusti Full GC) S tim bych si dovolil
polemizovat. V materiálech SCJP uvádí, že vynutit GC nelze, resp není to
garantováno. Sice o to můžeme požádat právě voláním tohoto příkazu, ale
GC se může rozhodnout, že nic neudělá. Záleží tak silně na implementaci
JVM (jak to mají napsané).
Arny
Zdenek Tronicek wrote:
Dost odstrasujici pripad.
Volani System.gc() by mel kazdy vedouci projektu zakazat. Krome nekolika
specialnich situaci, jako jsou performance testy, stejne k nicemu neni a
velmi casto nadela vice skody nez uzitku (po zavolani System.gc se vzdy
spusti Full GC a dochazi k presunu objektu z young generace do tenured).
Z.T.
--
Zdenek Tronicek
FIT CTU in Prague
Oto Buchta napsal(a):
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 filip.jir...@gmail.com
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 kamil.podle...@gmail.com
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 filip.jir...@gmail.com:
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
--
fi...@jirsak.org
Dne 28. ledna 2010 11:44 Zdenek Tronicek troni...@fit.cvut.cz
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
testovani odesilani mailu
Zdravim, jak testujete odesilani mailu? Mate zkusenosti s nejakym fake smtp serverem? Nasel jsem dumbster (http://quintanasoft.com/dumbster/), ale nemam s nim zkusenosti. Mate s nim nekdo zkusenosti nebo doporucite nejaky jiny? Diky blaf
Re: testovani odesilani mailu
My mame vytvoreny testovaci smtp server. Je to normalni server, akorat je nakonfigurovany tak, aby emaily zahazoval a neposilal dal. Posila emaily jenom na vyjmenovane adresy. 2010/1/28 Tomas Vojtech tom.vojt...@seznam.cz Zdravim, jak testujete odesilani mailu? Mate zkusenosti s nejakym fake smtp serverem? Nasel jsem dumbster (http://quintanasoft.com/dumbster/), ale nemam s nim zkusenosti. Mate s nim nekdo zkusenosti nebo doporucite nejaky jiny? Diky blaf
Re: testovani odesilani mailu
Tohle by vám mohlo pomoci: http://blog.novoj.net/2007/05/31/automaticke-testovani-odeslani-emailu/ S pozdravem, Honza N. Dne 29. ledna 2010 2:02 Ladislav Kulhanek ladislav.kulha...@gmail.comnapsal(a): My mame vytvoreny testovaci smtp server. Je to normalni server, akorat je nakonfigurovany tak, aby emaily zahazoval a neposilal dal. Posila emaily jenom na vyjmenovane adresy. 2010/1/28 Tomas Vojtech tom.vojt...@seznam.cz Zdravim, jak testujete odesilani mailu? Mate zkusenosti s nejakym fake smtp serverem? Nasel jsem dumbster (http://quintanasoft.com/dumbster/), ale nemam s nim zkusenosti. Mate s nim nekdo zkusenosti nebo doporucite nejaky jiny? Diky blaf -- -- Ing. Jan Novotný @@ http://blog.novoj.net Myšlenky dne otce Fura --
