Simon is suggesting decoupling your UI from any knowledge that it's working with a database - in your case, by leaving the ResultSet/connection/statement open so that you can return your resultset, you are effectively making the UI responsible for knowing that it has to close the ResultSet to free up a database connection. Bad idea. Instead, Simon suggests copying the resultSet data into some container that your application's GUI can use, letting you close the resultSet/connection/statement in the appropriate place while still having access to your data.
As a sample of how tying the GUI to the DB can burn you, I'm working to revamp an application whose GUI makes direct DB calls. Problem is, some of our clients have firewalls that block traffic on port 3306, the port our DB uses. So, we're revamping the application to communicate with a
servlet to get its data. The DB access is, unfortunately, coupled so much with the GUI that we're having to do a near total rewrite. Had it been appropriately initially architected, this change wouldn't be such a big deal.