ResultSet vs RowSet: Which one to choose and when?
I disagree with JR's answer. The RowSet is often a good choice, but as always, the best answer depends on your situation and your needs. Using a RowSet for everything won't yield dysfunctional code, but it can offer slower performance than a ResultSet (the common JdbcRowSet implementation is a wrapper for a ResultSet).
If you need to use your result object in modular code that requires a JavaBean, then RowSets meet the minimum requirements for Java Beans.
If you are developing code for a multithreaded/server app, then you must accept the concession that all Java Beans are mutable and therefore not thread-safe. As a result, neither Resultset nor RowSets are thread safe.
If you are writing code that consumes database queries and translates them into Java data model objects for use in the rest of your application, then it is likely that RowSets are less performant than Resultsets.
In a lot of code that I've been writing, when I receive a JDBC database query, I've been simply using the Resultset to process the retrievd rows immediately into a List of data model objects. The Resultset doesn't even survive the method call that performs the translation. In my opinion, this is good ... because Resultsets (and therefore RowSets) consume a lot of resources, and you want them to be available for gc as soon as you can.
In this mode, I don't even need any of the newer features of Resultset, let alone RowSet. I simply iterate forward once through the set and generate a List of result rows.
There are situations in which RowSets are highly desirable. Since RowSets are serializable and ostensibly "lightweight", the disconnected CachedRowSet (for example) represents a reasonably efficient mechanism for transmitting database query results between locations, particularly if you want the data to be updateable in situ. Of course, you could also serialize and transmit a List of objects.
RowSet
RowSet is almost always the right choice, it is more full featured and has all the benefits you listed as well as having specialized implementations for special purposes, like the disconnected CachedRowSet which is what I always use when the data will fit into memory, so I can release the connection back to the pool as quickly as possible to be reused.
ResultSet should never be part of a public contract.
A connected ResultSet/Rowset should never escape the method or at worst the object that created them. At least with a RowSet you can disconnect it and the client doesn't have to care about the implementation. *Unless you are writing JDBC specific library code that interacts or relies on ResultSet specific features or contracts.
If you are just transferring the results of a query, JDBC specific classes should be part of your public contract.
Ideally you want to materialize RowSet/ResultSet contents to typesafe Domain Objects to pass around.
In most cases you want to materialize a List/Set of domain objects to manipulate and work with instead of coupling your code directly to the JDBC api.
Many modern takes on a ResultSetMapper<T> class exist to handle generating typesafe domain instances using a Visitor pattern because this is the idiomatic way of doing things.