Martin Desruisseaux - 09/Mar/08 04:54 PM - edited GridCoverage2D had a finalizer a few years ago. I had long hesitation about it and finally removed it. A google search on "Java finalizers" gives a list of articles classifying finalizer in a "Java Hall of Shame". I remember they were some articles by Sun temself. There is also an IBM article titled "Why finalizers should (and can) be avoided": http://www-128.ibm.com/developerworks/java/library/j-jtctips/j-jtc0319a.html In short, finalizers are useful for releasing some native resources that could not be otherwise released by the garbage collector. But except for those few cases, it seems to cause more hurt than good. Finalizers put more pressure on the garbage collector (a finalized object must first be pushed in a finalizer queue, waits for its execution in an undetermined thread - which pose thread safety issues -, then wait for a new garbage collection cycle before they get effectively collected). Every fields hold by the GridCoverage2D may be retained longuer than they would otherwise be, including the PlanarImage reference (which I assume is the target of the proposed finalizer method). I assume that the intend was to invoke PlanarImage.dispose() on GridCoverage2D finalization. In addition of increasing garbage collector pressure (which may leads to the opposite of the intented effect, because of longer retention of the image reference), it is also unsafe. It would be safe if the image reference was private and if no getter method could return, directly or indirectly, a reference to this image. But this is not the case. The PlanarImage can still in use by anyone outside the GridCoverage2D class, for example the result of a Resample operation. We could invoke GridCoverage2D.dispose(false) which disposes the PlanarImage only conservatively, but this check is approximative and can be wrong. With an explicit GridCoverage2D.dispose(boolean) method, developpers invoke it only if they want. With a finalizer() method, it would be invoked in all cases, probably causing hard-to-track bugs in applications using the PlanarImage outside the GridCoverage2D. And most of all, the benefit compared to waiting for the garbage collector to collect the PlanarImage seems very hypothetical - it may actually be counter-productive in my understanding of the articles suggesting to avoid finalizers.

Simone Giannecchini - 10/Mar/08 03:32 AM Same applies to AbstractGridCoverageWriter

Andrea Aime - 04/Apr/08 07:31 AM Hey Simone, this one has been fixed, or not?

Simone Giannecchini - 04/Apr/08 08:52 AM backported to 2.4.x

Jody Garnett - 04/Aug/08 03:25 PM So is this one closed for 2.5-M3 or not?

Simone Giannecchini - 04/Aug/08 04:39 PM I left it open for feedback, but it seems that we are ok with closing it :-)