jdbc drivers and memory leaks

some conversation in one of the other topics brought to mind something i have been wondering of late. back in the old days (1998), i remember that early jdbc driver implementations came with warnings that programmers should explicitly close all ResultSets and Statements, else memory leaks could occur.
i have assumed that this is no longer the case, but i still cannot get out of the habit. anyone know how "memory-safe" jdbc drivers are these days? are type-4 drivers inherently safe (and type-2 inherently unsafe)?

any 'pure java' drivers should be safe.

Don't rely on any undocumented behaviour. If the interface or driver says it's okay to leave open stuff, then you're on. Otherwise, good practice and safe programming suggests you close anything when you've finished with it.
If I look at the latest java.sql.Statement doc, it says that the previous ResultSet obtained from executing the Statement is automatically closed when you re-execute the Statement to get a new ResultSet. The Statement.close() doc also says
Releases this Statement object's database
and JDBC resources immediately instead of waiting for
this to happen when it is automatically closed.
It is generally good practice to release resources as soon as
you are finished with them to avoid tying up database
resources.
--Jack Shirazi
JavaPerformanceTuning.com

If the interface or driver says it's okay to leave open stuff, then you're on.
Even then - I'd say, stick to what the interface says, not the driver. You may well find it desireable to change drievers later.
As for making sure you close things when you're done with them - always good practice, I think. It's great that the APIs offer some extra guarantees for automatic closure in certain common instances - but they don't cover all the problems you might have with unnecessary open connections / statements / resultsets. E.g. when you execute a new Statement, you automaticlly close the previous ResultSet. Great. But what if you are done with the statement? If it was just held in a local variable, or if you null out whatever other references were held, then it will eventually be closed as part of garbage collection. Probably. But why wait? It may be tying up needed resources in the mean time. Or you may have an extra reference to the statement which prevents GC - this is a problem in itself, but at least you can minimize its effect by ensuring that the database resources linked to the JVM's Statement object are freed up, even if the Statement itself is still occupying memory.
I don't think I've ever heard of any good argument not to close things promptly as you (John) were originally taught. It may turn out to be unnecessary, but I don't think it's ever a bad thing. So keep on doing it.

Rod Johnson maintains the activity for developing JDBC abstraction layer.
http://sourceforge.net/projects/springframework/
In my last project I got tired of writing endless similar functions for getting data from database. Inspired by article at Javaworld I developed my own set of classes for executing sql statements...to find some time later that this issue is already thought of by expert

Hope SpringFramework would release stable version soon.