• Post Reply Bookmark Topic Watch Topic
  • New Topic

Not all JDK libraries updated with streams and lambda functions?

 
S G Ganesh
Author
Ranch Hand
Posts: 93
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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

or

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?
 
Tim Cooke
Sheriff
Posts: 3290
153
Clojure IntelliJ IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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)
 
S G Ganesh
Author
Ranch Hand
Posts: 93
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.
 
Stephan van Hulst
Bartender
Posts: 6583
84
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Campbell Ritchie
Marshal
Posts: 52513
118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Cay Horstmann points out in a blog that they appear to have forgotten to add a lines() method to Scanner.
 
Tim Cooke
Sheriff
Posts: 3290
153
Clojure IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Rob Spoor
Sheriff
Posts: 20817
68
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!