I am writing JDBC code and realize that using streams/lambda functions can simplify programming in JDBC:
If ResultSet interface had been updated with forEach() method or stream() default methods (as in Collections API - List interface for example), this could would have become considerably simple, like
I checked many other libraries and some of them seem to be updated (e.g., NIO.2 - File class has methods that return Stream<String>). But there are many others (such as jdbc API) that hasn't been updated. Any idea why?
Interesting, I hadn't realised this. Does that count as a design smell?
I would certainly hope to see it in future releases as it sure would be useful. In the meantime though, there are a handful of third party libraries that give you this functionality, for example JOOQ.
(p.s. I added code tags to your post to make your code more readable. You can learn how to use them here -> UseCodeTags)
Tim Driven Development
S G Ganesh
posted 3 years ago
I would of course consider it as an "architecture smell": Consistency is important for design - what is done in one place should be done in the same say in other places as well. This avoids "surprises" to the users.
Thanks for pointing out JOOQ - looks interesting.
On related topic, with the emergence of NoSQL databases, what would be the future of JDBC? Of course this is looking through the crystal ball, but just curious on directions of JDK evolution.
S G Ganesh wrote:On related topic, with the emergence of NoSQL databases, what would be the future of JDBC? Of course this is looking through the crystal ball, but just curious on directions of JDK evolution.
This is a pretty common reaction when new things arrive on the scene. "Now we have awesome thing x, what will become of old thing y?". However, given the prevalence of relational databases in the industry I can see a healthy interest in developing JDBC for many years to come.
If ResultSet would have a forEach method, what would be the argument to the Consumer? Likewise with stream(), what would be the element type of the stream?
That's the big issue with ResultSet - although you can loop through it, you don't get different objects - it's the internal state that changes. I agree with Stephan that this makes a questionable design:
Stephan van Hulst wrote:I think ResultSet is a big design smell to begin with. It's really annoying that it mixes set operations with row operations. A ResultSet should have been an iterable/stream of rows.