There are various attempts to get Java and SQL to behave with each other. We have JDBC, OR mappers like Hibernate and EclipseLink, language support like in Groovy. All of those have advantages and drawbacks.
JDBC is powerful but low-level. The API is not really friendly. You need to write a lot of boiler plate code for even simple tasks.
Languages like Groovy wrap JDBC to make simple tasks simple. The code becomes much more readable but changes in the database schema become runtime errors.
OR mappers try to turn a relational database into a OO database. It works better than you’d expect but it also causes odd problems and leaks into design of your code: You must no’t use the ID field in equals, hiding the session in a thread-local variable can cause exceptions when you use lazy loading, failing to understand the requirements of the OR mapper causes spurious bugs. At least the OR mappers will complain when the schema changes.
Enter jOOQ. It’s like a OO wrapper for JDBC:
- You get all the power of JDBC if you need it
- The readability of a fluent interface
- The database schema is part of the code (so you get compile time errors if it changes)
- You can iterate over results as if they were a plain Java collection
Related:
Dark Views 
[…] https://blog.pdark.de/2011/11/23/peace-between-java-and-sql/ […]
[…] https://blog.pdark.de/2011/11/23/peace-between-java-and-sql/ […]