Roel De Nijs wrote:
A.J. Côté wrote:If not, add more memory consuming code to give an opportunity to the jvm to call finalize() before your program terminates. This is how finalizers work.
That's a very nice example, but it still doesn't cover the unpredictability of this method being executed or not. And you could add all the memory consuming code you want, but if your program uses/relies on finalize() to get some task done and GC doesn't kick in, you're toast! So why spend time in implementing a method of which you have no guarantee it will be executed at all
Roel De Nijs wrote:
A.J. Côté wrote:It is typical to ALWAYS use finalize to make sure a connection, thread or anything poolable is returned to its pool when there is no more reference to the wrapper object wrapping the real poolable object, more precisely when the jvm decides it is time to call finalize on the wrapper object because there is no more reference pointing to it.
Typical You have to be kidding! I've been developing Java applications for over more than 10 years and have NEVER used the finalize() method. Maybe once or twice in some test code to confirm how unpredictable this method really is. And to prove how unpredictable this method really is, here is a very simple code snippetWhen I run this application on my computer, I expect to see 10x "in finalize", but there was no output at all. When I incremented the number of iterations to 1000, 10_000 and even 100_000, still no output. When incremented to 1_000_000, a bunch of "in finalize" were printed (but definitely not 1_000_000). When you run this on your own computer, the results might be different.
Vineeth Vasudevan wrote:OnLoad Javascript*