Not really. For one thing you don't know the number of rows until you have read them all, and for another thing it is not object-oriented.
Create a class that represents a row of your table. Each time you read a row of the table, create an object of that class and fill it with the column data. (This is called a DAO, Data Access Object). Then add that object to a collection; ArrayList would do nicely.
Another option you might want to consider is having a factory class or method somewhere that provides the java.util.Collection object, instead of making it obvious you are using ArrayList or whatever. Just use an Iterator to traverse the collection instead of using get(i) or size(), so you don't have an implicit assumptions about the nature of the Collection.
It seems most applications running against a daatabase sooner or later evolve into having more data to return than you want to actually have in memory at one time. If you hide your actual Collection (or List, or Map) implementation, you gain the opportunity to change the Iterator implemention too. That lets you play the same kinds of games as EJB CMP and CMR, where you can hide the result set dependency inside the Iterator. [ February 03, 2006: Message edited by: Reid M. Pinchback ]