spring-data-relational VS StreamEx

What do you think of Spring Data JDBC (https://spring.io/projects/spring-data-jdbc)?

What do you think of Spring Data JDBC?

Link to GitHub: https://github.com/spring-projects/spring-data-relational/blob/main/spring-data-relational/src/main/java/org/springframework/data/relational/repository/Lock.java

I would ignore the hipster jOOQ and similar and start with Spring Data JDBC https://spring.io/projects/spring-data-jdbc

This makes Spring Data JDBC a simple, limited, opinionated ORM.

Though JPA is fine, and yes hibernate can be used under the hood. When it comes to spring it is mostly what level of abstraction you want. Or you could go with JDBC. And you have a spring data JDBC for having a similar abstraction as to the JPA one.

This is not correct. You're thinking Spring Data JPA [1]. Spring Data JDBC [2] does _not_ use any Hibernate nonsense.

[1] https://spring.io/projects/spring-data-jdbc

The data moved from the awesome-but-confusing DynamoDB... into PostgreSQL✨, using Spring Data JDBC.

I didn't have much experience with Hibernate and Spring (was using JavaEE prior), it could very possibly be the case, that the team simply misused Hibernate. We might have used n+1 queries, eager loading (although I mildly remember we fixed this), oh and we had the old id generation via sequence in Hibernate, that was really pain to optimize properly. Oracle 11 does not have identity generation. I remembered this only becuase I created an issue at the time. Still not implemented, but can't blame them, who the hell uses sequences as ID generation nowadays.

I really like StreamEx. I do not know why people do not use it often, the syntax is just wonderful.

It gets more perverse if you need to flatMap, or transmute components of map types, etc. If you want even more power, take a look at https://github.com/amaembo/streamex. This sort of container manipulation bread and butter for business processing. I use it every day, sometimes with a dozen operations. This (with liberal use of `final` values) makes for some pretty functional-looking code.

I'll grant you the Kotlin or Scala version is slightly more compact. But not fundamentally different, like the Go version.

I (and the pretty much every language designer in the post-Java era) disagree with you about checked exceptions, but that's a whole different thread...