Skip to content
Kaumei JDBC Kaumei JDBC Kaumei JDBC

Why Kaumei JDBC

Why this project exists

Section titled “Why this project exists”

Plain JDBC is direct and universal, but it leaves a lot of mechanical work in application code. You open resources, bind parameters, map result sets, and repeat the same patterns again in the next method.

Frameworks can reduce that work, but they often bring their own model for queries, mapping, lifecycle, or transactions. That can be the right trade-off. It can also be more than a project needs.

Kaumei JDBC keeps SQL explicit and generates the repetitive JDBC code at build time.

How it compares

Section titled “How it compares”

Different database access tools put the work in different places:

  • JPA and implementations such as Hibernate or EclipseLink build a runtime persistence model from entity mappings. Hibernate uses proxies and bytecode enhancement for parts of that model, and SQL is generated from mappings and query APIs at runtime.
  • JDBC gives direct access to the database, and executes the SQL you pass to it. It does not add a mapping model, reflection, or code generation by itself, but it keeps parameter binding, resource handling, and result mapping in your code.
  • jdbi keeps SQL visible, but SQL Object APIs, Java proxies, and reflection-based mappers are runtime mechanisms.
  • jOOQ is SQL-centred and powerful, with a generated DSL for modelling database structures and queries.
  • MyBatis maps explicit SQL to Java objects through XML and annotations. It supports dynamic SQL and uses runtime mapping mechanisms, including proxy and reflection-style infrastructure.
  • Spring JDBC reduces JDBC boilerplate in Spring applications through templates and callback APIs. It stays close to user-provided SQL, while object mapping is either handwritten or handled by runtime helpers such as bean-property mappers.

Kaumei JDBC is for the case where you want to keep writing SQL, but do not want to keep writing the same JDBC scaffolding around it.

What Kaumei JDBC optimises for

Section titled “What Kaumei JDBC optimises for”

Kaumei JDBC generates ordinary Java code that you can read, debug, and understand.

Nothing happens at runtime that was not decided at compile time. Runtime values can still provide parameters,

  • Generated at build time: Database access code is generated only during compilation. No code is generated at startup or during runtime.
  • No hidden control flow: The generated code is the code that executes. There are no runtime query models, mapper registries, proxy layers, or other hidden framework mechanisms.
  • No reflection: Generated database access code uses direct calls to Java methods and JDBC APIs.
  • No SQL injection by design: Runtime parameter values are never concatenated into SQL strings. All parameters are bound through PreparedStatement using JDBC ? markers.
  • Good candidate for native-image builds: Generated database access code avoids reflection, runtime proxies, bytecode enhancement, and runtime code generation. Native compilation still depends on the JDBC driver and other libraries in your application.
  • SQL remains plain SQL: SQL is written directly in Java source code instead of being generated from a query DSL. It remains easy to read, review, and debug.
  • Minimal runtime dependencies: The generated database access code depends only on the JDK and JDBC APIs. Annotation processor dependencies stay on the build classpath and do not become application runtime dependencies.
  • Integration friendly: Works with plain JDBC and integrates into existing applications, including Spring, Spring Data, Hibernate, or custom infrastructure.

When to use Kaumei JDBC

Section titled “When to use Kaumei JDBC”

Kaumei JDBC is a good fit when:

  • You write SQL directly and want it to stay reviewable in the codebase.
  • You want generated JDBC code instead of handwritten plumbing.
  • You want database access that can be inspected in generated Java.
  • You build services, tools, or modules where SQL is already part of the design.
  • You want to adopt it gradually beside existing JDBC or framework code.

When not to use it

Section titled “When not to use it”

Kaumei JDBC might not be the right fit when:

  • Your object model drives persistence and SQL should be generated from it.
  • You need transparent object caching or lazy entity graphs.
  • You expect the Java model to generate the database schema.
  • You need to support several databases with one service, and their SQL differs often enough that one source-level SQL statement is no longer practical.
  • You want a query builder instead of writing SQL statements.

What Kaumei JDBC is not

Section titled “What Kaumei JDBC is not”
  • An ORM framework like Hibernate or JPA.
  • A query builder like jOOQ.
  • A caching layer for database results.