Finalize prevents "resource leak"?

Question

As far as I can tell, " +Effective Java+ " (by Joshua Bloch) is the most recommended Java text. Therefore, I am assuming the author is credible, maybe on par with the best on this forum. Then, here is a quote from the book:
".... there is a severe performance penalty for using finalizers... So what should you do instead of writing a finalizer for a class whose objects encapsulate resources that require termination, such as files or threads? Just provide an explicit termination method, and require clients of the class to invoke this method on each instance when it is no longer needed."
I question the advisability of designing a class such that the design says "oh. by the way. when you are done using an instance of it, don't forget to call this method." Would not such a design lead to hard to find, easy to forget, resource leaks (same idea as memory leaks ). Is such a (dangerous?) practice used in real-world apps?
btw:
The issue of finalizers arose while reading about java.awt.Graphics . I read that if "g.dispose()" was not called on every instance of Graphics , if run long enough, with 100% certainity, an app would come crashing down. Some resource is exhausted. Know when it must be explicitly called, and then always put that method in a finalize block.

Answer 1

tatsuke wrote:
try {
ArrayList<Double> list = new ArrayList<Double>();
for(int d = 0; d < Double.MAX_VALUE;d++) {  list.add(new Double(d));  }
} catch (java.lang.OutOfMemoryError e) {
// forces gc to kill all possible objects, each's finalize block is executed?
// next, not sure what to do in any practical sense.
// just checking that i understand what is going on.
First of all, If I ever find any code like this in an production environment during a code review, then the author of that code will get a very strict talking-to at least.
I can't begin to tell you how wrong this is and at how many levels.
First of all: Who tells you that the OOM-Error is thrown in this code and not in an entirely unrelated code in another Thread that happens to be the first one to request too large a block of memory? (Not unlikely, since you allocate a lot of tiny objects and the OOM-barrier can easily be hit by another thread that tries to allocate a 512k buffer for some I/O operation.
Next: you're taxing the memory settings of the JVM, forcing it to go up to its maximum size, even when the actual requirement would a fraction of the maximum size and thus potentially forcing your application (and others) into swap and slowing them down to a grinding halt, effectively producing a denial-of-service.
Next: you produce an infinite loop, because you'll never reach Double.MAX_VALUE (try printing "Double.MAX_VALUE" and "Double.MAX_VALUE - 1d" and tell me the difference).
Next: no-one said that it's possible that the object is never collected and never finalized in all situations. Of course there are situations when it has to be collected (OOM is about the only one that comes to my mind, at the moment). But that doesn't mean that you can rely on finalize() being called in all situations. Note that nothing in the spec tells you that the GC must run when you run out of file descriptors. Running the GC could help, if someone forgot to close a stream, but it is not enforced.
Next: yes, I'm pissed of at something entirely unrelated and you just happen to be there. Sorry for that. I still think the content of my comments is correct.