Enforcing proper use seems beyond the capabilities of an
API.  Hence Eckel's suggestion to use finalize() as a debugging
aid: for an object that *should* be dispose()d, you imlement
a finalize() that tests the object's status and whines if the
object became garbage with no dispose().  It's not perfect --
you can't be sure all objects will be finalized -- but it may
help you catch a few bugs.

    Not only does GC offer no real time guarantees, it offers
no guarantees at all.  The JVM can exit -- usually *does* exit --
with garbage uncollected, hence with garbage un-finalized.  If
you use finalize() for something important, there is every chance
that the important something will never be done at all.  (No, not
even with runFinalizersOnExit(), although I'm not deeply enough
versed in the matter to explain all the whys and wherefores: in
this I'm just trusting the word of others.)

    Summary: If it needs doing, don't rely on finalize() to do it.
Use finalize() only when you're perfectly happy if "it" remains
un-done when the JVM exits.

Actually, its not an aesthetic at all.  The garbage collector treats
objects with finalize method differently, to the point where you can end
up with more garbage lying around. It can affect performance of the GC
to the point that you'll get OOME errors more frequently.  Also, if the
"this" reference escapes the finalize method, it can interfere with the
GC further.

But since finalize() is only guaranteed to run before trying to reuse
memory (not when object is made available for GC) you can't be certain
that it will run. It will also only run once, even if the object becomes
reachable after finalize() is invoked by the GC system.

Anecdote:
I have seen problems with this in one of my projects. Our installation
team complained that the server ran out of file handles, even if they
increased the ulimit. We asked what they did to trigger this and they
said "nothing, we just install the application, run our tests and then
suddenly we have exceptions and the application has aquired X file
handles. Sometimes it releases them again after a while, but then
exception comes back after a few more hours." X in this case was close
to the setting by ulimit. Initially we were unable to reproduce this but
we did find a class releasing a stream without closing it. The fix
remove problem.

So, why did they get the error while we never saw it during
development/testing? The class leaking the file handle was a monitoring
class that got to run every few seconds and hardly created any garbage
at all. So we used up file handles faster than memory IFF nothing else
ran. Of course that never happened for us, we would either run unit
tests or duration tests, but no test just started the application and
left it alone for >12 hours (the time it took us to trigger the error
once we knew the problem). Since the installation team often let this
application alone after installation they triggered the error. The
application was robust (apart from causing exceptions ;-) ) that after a
while it would run scheduled tasks that caused enough garbage to invoke
a GC which in turn caused the file handles to be released.

Now we actually include statistics of file handles during load and idle
and verify that we get expected results (which sometimes causes us to
change code or change our expectations).

//Roger Lindsjö

Neither does finalize().

The JVM is free to put off the collection of any given object for as
long as it wants, and to finalize objects in any order it feels like.
Objects that have not been collected when the program ends are likely
never to be finalized.  This is an intrinsic feature of Java's
finalization and can't be "worked around"; even the
runFinalizersAtExit method doesn't guarantee that finalizers will ever
be run (trivially, if the JVM dies of a KILL signal, it never gets a
chance to finalize anything, but there are other ways to cause it with
Sun's JVM).

Since Java has neither destructors nor C#'s using statement and
IDisposable interface, the idiom for using and discarding resources in
a controlled, guaranteed way is similar to this:

InputStream source = new FileInputStream ("foo.dat");
// do not put code here, ever.
try {
 readDataFrom (source);
} finally {
 source.close ();
}

Using finally like this does guarantee that, regardless of whether or
not the code represented by readDataFrom succeeds, the source stream
will be closed.  The same pattern works for any releaseable resources:
explicit locks, database connections, and so on.  It's a construct
that should be familiar to any Java programmer, and while it's a
little verbose, it works rather well and gives the programmer complete
control over the lifecycle of the resource.

Joe Seigh wrote :

In the following I left out all the try/catch/finally for brevity.

Note to new-comers. DO NOT use this pattern. It is flawed and you may
end up with many connections left open due to when the GC calls
finalize!

public class SQL
{
 private Connection conn;

 public SQL()
 {
   conn = Databasae.getConnection();
 }

 public Data getData()
 {
    Statement st;
    ResultSet rs;
    Data data = new Data();

    st = conn.createStatement();
    rs = st.executeQuery("select id,name from table");

    while ( rs.next() )
    {
       // code to fill data
    }

    return data;
 }

 public viod finalize()
 {
   conn.close();
 }
}

and to use this:

-------------------------------
SQL sql = new SQL();
Data data = sql.getData();
sql = null;
-------------------------------

So from my thinking:
- a connection is established in the constructor
- a method retrieves information
- when sql is set tu null, the only reference goes away.
- some time in the future the GC calls the finalize method.

In practice, the connection appeared to be closed before the "while (
rs.next() )" loop completed.

When I made the following change, the problem went away.

public class SQL
{
 public Data getData()
 {
    Connection conn;
    Statement st;
    ResultSet rs;
    Data data = new Data();

    conn = Databasae.getConnection();
    st = conn.createStatement();
    rs = st.executeQuery("select id,name from table");

    while ( rs.next() )
    {
       // code to fill data
    }

    conn.close();

    return data;
 }
}

I went back and forth several times between the to ways, and the
results were consistent.