I have seen recent updates in term of record sets being updated so that we can scroll back and forth through the data it points to.
My question is why they were initially designed for a forward only traversal. Is there any impact using the new version?
"new version" is about 5 years old.
forward only : it is the easiest way to implement. It is easiest to implement a Queue(FIFO) rather than a deque or linked list. Since the JDBC driver has to read the record from the DB, it can make them EASILY available to the ResultSet reader FIRST COME FIRST SERVE.
Later on, they realized that some desktop applications and some rich web based apps might want to scroll forward and backward without having to store the intermediate representations, they decided to implement it.
Then came the updatable ResultSets where you can update the columns/rows of a ResultSet.
It's a long time since I've looked at some of this stuff, but I am pretty sure that originally the data was streamed, and for many of the JDBC drivers the Recordset was tied to low-level cursor operations in the database.
The only impact from using may perhaps be on memory usage - but in nearly all business cases you aren't going to notice and I wouldn't worry about it. When dealing with large datasets you might need to look at how you fetch your data but I mean large in the "enterprise" sense of the word - millions, if not billions of records.
Packing too many features in to the first version of JDBC would have slowed down the adoption of JDBC, since the vendors would have taken longer to implement it.
Scrollable result sets is a relatively rarely used feature in JDBC, so it wasn't essential to have it there from day one. The same applies to the other fancy features in JDBC 2 and 3.