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 takes a smaller path. SQL stays visible in the Java source. The repetitive JDBC code is generated 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”
  • Generated at build time: implementations are generated during compilation. Once the application is built, the generated database access code is fixed until the next build.
  • No reflection: generated database access code calls ordinary Java methods and JDBC APIs directly.
  • No runtime code generation: Kaumei JDBC does not generate code when the application starts or later while it is running.
  • SQL stays in the source: the SQL lives in the source code. Kaumei JDBC binds parameters and maps results around that SQL. Collection markers may expand to JDBC placeholders, but Kaumei JDBC is not a query builder.
  • Short runtime path: generated methods bind parameters and call JDBC directly. There is no runtime query model, mapper registry, or SQL generation step between your method call and JDBC execution. This keeps the runtime path small and predictable. Actual performance still depends on the JDBC driver, database, SQL, and transaction setup.
  • Good candidate for native-image builds: generated database access code does not rely on reflection or runtime code generation. Reflection, runtime proxies, bytecode enhancement, and runtime code generation often need extra native-image configuration. Kaumei JDBC avoids those mechanisms in its generated database access code. Native compilation still needs to be tested with your application, JDBC driver, and surrounding framework.

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.