Forem: Pavel Ponec

Native SQL in Java without JDBC boilerplate — meet Ujorm3

Pavel Ponec — Tue, 19 May 2026 10:38:40 +0000

If you've ever written raw JDBC, you know what's coming. Open a connection, create a PreparedStatement, set parameters by index (hope you counted right), iterate a ResultSet, close everything in a finally block, declare SQLException on every method signature… It's a lot of ceremony for "give me some rows."

I've been experimenting with Ujorm3, a new lightweight ORM library for Java 17+. Here's a realistic example — a JOIN query that maps results including a nested relation:

static final ResultSetMapper<Employee> EMPLOYEE_MAPPER =
        ResultSetMapper.of(Employee.class);

List<Employee> findEmployees(Connection connection, Long minId) {
    return SqlQuery.run(connection, query -> query
            .sql("""
                    SELECT e.id, e.name, c.name AS "city.name"
                    FROM employee e
                    JOIN city c ON c.id = e.city_id
                    WHERE e.id >= :minId
                    """)
            .bind("minId", minId)
            .toStream(EMPLOYEE_MAPPER.mapper())
            .toList());
}

Let me walk through what makes this tick.

Fluent API

The whole operation is one readable chain. No juggling Statement objects, no passing things between methods — you declare the SQL, bind parameters, specify the mapper, and collect. Done.

Named parameters instead of positional `?`

Classic JDBC:

stmt.setLong(1, minId); // hope you counted correctly

Ujorm3:

.bind("minId", minId)

You reference parameters by name in the SQL (:minId) and bind them by name. No counting, no off-by-one errors when you insert a new parameter in the middle of a query, and the SQL stays readable.

No checked exceptions

SQLException is a checked exception, so vanilla JDBC forces you to handle or rethrow it everywhere — even when there's nothing useful to say. Ujorm3 wraps these internally, so your methods stay clean:

// JDBC — forced to declare or catch
List<Employee> findEmployees(Connection c, Long minId) throws SQLException { ... }

// Ujorm3 — nothing to declare
List<Employee> findEmployees(Connection connection, Long minId) { ... }

Smart object mapping — including relations

ResultSetMapper is a thread-safe class that prepares its mapping model on first use and reuses it across all subsequent calls. This significantly reduces overhead when processing a large number of queries.

Mapping is inferred automatically by default. You can optionally annotate your domain classes with standard jakarta.persistence annotations (@Table, @Column, @Id) for explicit control, but they're not required.

The interesting bit is how it handles relations. The aliased column "city.name" uses dot notation to map directly into a nested object — no extra configuration needed:

-- maps to employee.getCity().getName() automatically
c.name AS "city.name"

The library supports M:1 relations. 1:M collections are intentionally left out — a deliberate design choice to avoid hidden queries and N+1 problems.

Want compile-time safety? There's a metamodel for that.

The string-based alias approach works great for getting started, but if you want the compiler to catch typos in column mappings, the optional APT plugin generates Meta* classes from your domain objects. The query then looks like this:

List<Employee> findEmployees(Connection connection, Long minId) {
    return SqlQuery.run(connection, query -> query
            .sql("""
                    SELECT e.id  AS ${e.id}
                    , e.name     AS ${e.name}
                    , c.name     AS ${c.name}
                    FROM employee e
                    JOIN city c ON c.id = e.city_id
                    WHERE e.id >= :id
                    """)
            .label("e.id",   MetaEmployee.id)
            .label("e.name", MetaEmployee.name)
            .label("c.name", MetaEmployee.city, MetaCity.name)
            .bind("id", minId)
            .toStream(EMPLOYEE_MAPPER.mapper())
            .toList());
}

The ${placeholder} syntax in the SQL template and the label() method work together — the metamodel keys are type-parameterized descriptors that resolve column labels at runtime and carry full type information.

Automatic resource management

SqlQuery.run(...) handles closing the underlying PreparedStatement and ResultSet for you. No try-with-resources, no resource leaks if mapping throws partway through.

There's more than just `SqlQuery`

The library offers three levels of abstraction — pick what fits your use case:

EntityManager — the fastest path for CRUD on a single table using a primary key; generates the SQL itself.
SelectQuery — for fetching data including relations; supports type-safe Criterion filters composable with AND/OR operators; JOIN type (INNER vs LEFT) is inferred automatically from the nullable property of @Column.
SqlQuery — low-level, full native SQL control; what we've been looking at above.

`SelectQuery` in action

In many cases, the full SELECT statement — columns, JOINs, and WHERE clause — can be generated automatically by SelectQuery from the metamodel, so you don't have to write SQL at all. You still get the same object mapping under the hood.

First, set up the shared context and entity manager (once, typically as static fields):

// EntityContext controls SQL logging; false = no param values in logs
static final EntityContext CTX = EntityContext.ofSqlInfoWithParams(false);
static final EntityManager<Employee, Long> EMPLOYEE_EM = CTX.entityManager(Employee.class);

Then the query itself:

List<Employee> findEmployees(Connection connection, Long minId) {
    return SelectQuery.run(connection, EMPLOYEE_EM, query -> query
            .columns(true)                            // select all columns, including foreign keys
            .column(MetaEmployee.city, MetaCity.name) // add the city.name JOIN column
            .where(MetaEmployee.id.whereGe(minId))    // WHERE id >= minId
            .tail("ORDER BY", MetaEmployee.id)        // append raw SQL fragment at the end
            .toList()
    );
}

A few things worth noting:

.columns(true) expands to all mapped columns of Employee, including foreign key values (e.g. city_id). The true argument does not affect JOIN generation yet — that is driven by the next call.
.column(MetaEmployee.city, MetaCity.name) adds a specific column from a related entity. The library resolves which JOIN to emit based on the metamodel.
.where(...) takes a type-safe Criterion. Conditions compose naturally with .and() / .or(), and because they're built from metamodel descriptors, a typo in an attribute name is a compile error, not a runtime surprise.
.tail("ORDER BY", MetaEmployee.id) appends a raw SQL fragment after the generated WHERE clause — a handy escape hatch for ORDER BY, LIMIT, window hints, or anything else the query builder doesn't cover.

The result mapping works exactly the same way as in the SqlQuery examples above — same ResultSetMapper machinery, same dot-notation for nested objects.

Performance

Instead of reflection, the library generates and compiles its own bytecode at runtime for reading and writing domain object fields — performance comparable to handwritten code. In benchmark comparisons against Hibernate, Jdbi, MyBatis, and others (running on PostgreSQL and H2) it performs very well. The entire compiled module including Ujorm3 itself is under 3 MB, which is nice for microservices.

What this is NOT

Not Hibernate. No entity scanning, no session factory, no proxy objects, no lazy
loading surprises. You write SQL, you get objects back.

Not jOOQ either — there's no Java DSL for building queries. You write plain SQL strings, which means you get full access to any database-specific syntax: window functions, CTEs, vendor extensions, whatever your DB supports.

Getting started

Java 17+, final version 3.0.0 available on Maven Central:

<dependency>
    <groupId>org.ujorm</groupId>
    <artifactId>ujo-core</artifactId>
    <version>3.0.0</version>
</dependency>
<dependency>
    <groupId>org.ujorm</groupId>
    <artifactId>ujorm-orm</artifactId>
    <version>3.0.0</version>
</dependency>

Optional APT plugin for metamodel generation:

<annotationProcessorPaths>
    <path>
        <groupId>org.ujorm</groupId>
        <artifactId>ujorm-meta-processor</artifactId>
        <version>3.0.0</version>
    </path>
</annotationProcessorPaths>

Integration tests cover PostgreSQL, MySQL, MariaDB, Oracle, and MS SQL Server (all via Docker).

When does this make sense?

If you need JPA portability across databases or your company mandates a standard ORM, use Hibernate. If you want full SQL control, transparent behavior, and no hidden magic — and you'd rather not write raw JDBC — this hits a nice sweet spot.

Useful links:

Curious whether others are using similar lightweight wrappers, or if you've landed on
a different approach for native SQL without going full ORM.

Ujorm3 is out: a tiny, type-safe ORM for JavaBeans & Records

Pavel Ponec — Mon, 18 May 2026 08:40:16 +0000

Do the simplest thing that could possibly work. — Kent Beck, creator of Extreme Programming and pioneer of test-driven development.

Today, I would like to introduce the final version of the Ujorm3 library with a newly written ORM module for working with JavaBean and Record objects in the context of relational databases. The goal of this module was a transparent solution without additional dependencies, supporting type-safe construction of SQL statements.

For fast manipulation of domain object data, the library compiles its own bytecode at runtime, achieving performance comparable to handwritten code. The core of the library intensively utilizes the Typed Key Pattern design pattern. Two interfaces in particular were carried over from the original version of the Ujorm library — Ujo and Key. Both interfaces applied this pattern back in 2007, even before the pattern received its name.

The Typed Key Pattern design pattern represents a technique for reading and writing domain object values through its key API, replacing traditional getters and setters with an internal property map. Keys are type-parameterized descriptors carrying information about the data type (or a default value) and, thanks to generics, ensure type safety without casting; they also allow mass operations on attributes without reflection. In terms of internal representation, this approach corresponds to the Typesafe Heterogeneous Container concept, which was first systematically published by Joshua Bloch in May 2008 in the second edition of the book Effective Java following the introduction of generics to the Java language.

Let me remind you of some basic information from the previous blog: the default mapping of entity attributes to database columns is described using JPA annotations from the Jakarta package. The @Column annotation is used for mapping attributes to columns, and @Enumerated is used for mapping enum types. The table name is declared with the @Table annotation.

Since the library does not use any binary-modified classes, partial column updates in an UPDATE statement require providing a list of modified attribute names (for example, as a String[] array) or the original object, from which the library creates this list itself. A single database table can be serviced by several classes — typically representing a subset of the entity.

One of the goals of the new library was to find the optimal balance between utility value and minimalist source code. The author believes that such an approach has a positive impact on minimizing errors and significantly extends the lifespan of the library. However, certain limitations arise from this approach. For example: The library does not support lazy-loading and supports only M:1 relationships when mapping relations.

The ORM module of the Ujorm3 library offers a set of tools with different levels of abstraction for database commands. Choose the solution that best suits your specific requirement:

EntityManager — the fastest way to handle CRUD (Create, Read, Update, Delete) operations with a single table using a primary key. For such elementary cases, the class generates the SQL command itself.
SelectQuery — a tool primarily designed for fetching data, including relations. It supports filtering data using type-safe Criterion objects, which can be arranged into a binary tree (using AND and OR operators). An alternative is using the bind() method. For specific cases, the beginning and end of the generated SQL command can be manually appended.
SqlQuery — a low-level universal class for general requirements. It allows writing native SQL while maintaining safety using the bind(), label(), and column() methods. Using a generic mapper, the library can automatically populate relational objects as well. The last two classes share a common ancestor, which can serve as a base for any future implementations.

Let's look at simple usage examples, starting with the low-level approach. The following method inserts a city into the database table (using a fluent API) and returns the identifier of the inserted row.

public Long insertCity(String name, String country) {
    return SqlQuery.run(connection(), query -> query
        .sql("""
             INSERT INTO city
             ( name,  country_code) VALUES
             (:name, :countryCode )
             """)
        .bind("name", name)
        .bind("countryCode", country)
        .executeInsert(rs -> rs.getLong(1))
        .findFirst().orElseThrow());
}

The next example searches for employees and fetches their data, including the city name. The ResultSetMapper class supports multithreaded access.

static final ResultSetMapper EMPLOYEE_MAPPER =
             ResultSetMapper.of(Employee.class);

public List<Employee> findEmployees(Connection connection, Long minId) {
    return SqlQuery.run(connection, query -> query
        .sql("""
             SELECT e.id  AS ${e.id}
             , e.name     AS ${e.name}
             , c.name     AS ${c.name}
             FROM employee e
             JOIN city c ON c.id = e.city_id
             WHERE e.id >= :id
             """)
        .label("e.id"  , MetaEmployee.id)
        .label("e.name", MetaEmployee.name)
        .label("c.name", MetaEmployee.city, MetaCity.name) // Key Path mapping
        .bind("id", minId)
        .toStream(EMPLOYEE_MAPPER.mapper()) // Generic mapping including relations
        .toList());
}

The MetaEmployee class is an automatically generated metamodel created using the optional ujorm-meta-processor APT plugin. However, mapping can also be written directly in the SQL SELECT statement at the column alias position in the format of dot-separated property names (properties, for example, boss.name). However, it needs to be enclosed in quotes (or other characters depending on the database type). If the DB column name matches the attribute, explicit mapping is unnecessary. For example:

SELECT e.id, e.name, c.name AS "city.name" FROM ...

The last example performs a similar SELECT using the SelectQuery class. Here, the columns(true) method loads all columns of the table, including foreign keys. The column(...) method adds another column to the mapping and can also handle multiple relations.

The relation type is determined by the nullable property from the JPA annotation: a mandatory object attribute (marked as nullable=false) generates an INNER JOIN relation type, otherwise it generates a LEFT JOIN. The beginning of the SQL statement can (optionally) be changed using the sql() method, and the end can (optionally) be appended using the tail() method.

final EntityContext CTX = EntityContext.ofDefault();
final EntityManager<Employee, Long> EMPLOYEE_EM = CTX.entityManager(Employee.class);

List<Employee> select(Connection connection) {
    return SelectQuery.run(connection, EMPLOYEE_EM, query -> query
            .sql("SELECT")  // Optional
            .columns(true)
            .column(MetaEmployee.city, MetaCity.name)     // INNER JOIN
            .column(MetaEmployee.boss, MetaEmployee.name) // LEFT JOIN
            .where(MetaEmployee.id.whereGe(1L).and(MetaCity.id.whereGe(1L)))
            .tail("ORDER BY", MetaEmployee.id)
            .toList()
    );
}

The code of the Ujorm3 project is thoroughly covered by JUnit tests. Integration tests are run via a Bash script (in the bin directory) against dockerized databases: PostgreSQL, MySQL, MariaDB, OracleFree, and MSSQL Server. More detailed information about the Ujorm3 library can be found on the homepage of the project — including additional examples.

A reference usage of Ujorm3 can be found in the PetStore project, which uses the lightweight Avaje library for dependency injection. The PetStore project then gave rise to a prototype web application called TopMovies for movie viewers — this application recommends movies to users based on how their ratings match a virtual group with similar preferences.

Apart from the Ujorm library, this project also has no other dependencies. Data is stored in an H2 database, or optionally in PostgreSQL. Although the project is not publicly available, you can freely try the prototype at the provided link (the number of fictitious users is limited).

Web Links

Homepage — is part of the Ujorm3 project hosted on GitHub.
PetStore — a sample open-source application demonstrating the Ujorm3 library. It uses the ORM module for database queries and the Element class to build the UI.
TopMovies — a prototype application for recommending movies based on the alignment of user ratings with a virtual movie group.
JavaDoc — class description.
An ORM performance comparison — comparing performance and other metrics with Hibernate, Jdbi, MyBatis, and other libraries. Tests run on PostgreSQL (in Docker) and H2 (in-memory) databases using Java 25.

ORM library Ujorm 3.0 is released

Pavel Ponec — Fri, 15 May 2026 10:40:12 +0000

Today, the final version of Ujorm 3.0.0 was released, featuring a completely new ORM module for working with JavaBean and Record objects. The goal was a transparent solution with no additional dependencies, supporting type-safe construction of SQL statements.

Ujorm3 requires Java 17 or higher:

<dependencies>
    <dependency>
        <groupId>org.ujorm</groupId>
        <artifactId>ujo-core</artifactId>
        <version>3.0.0</version>
    </dependency>
    <dependency>
        <groupId>org.ujorm</groupId>
        <artifactId>ujo-orm</artifactId>
        <version>3.0.0</version>
    </dependency>
</dependencies>

More information is available on the project's homepage on GitHub.

Stop Debating ORM vs JDBC — Measure These 5 Things First (Java Guide)

Pavel Ponec — Sat, 25 Apr 2026 05:47:16 +0000

Most "ORM vs JDBC" discussions are opinion wars.

After building and benchmarking data-access layers in Java, my takeaway is simple:

you should not choose by framework brand, but by measured query behavior.

In this post, I’ll share a practical checklist you can apply to any stack (Hibernate, MyBatis, JDBI, jOOQ, custom JDBC, or lightweight ORM tools).

Why teams get stuck in the same loop

You’ve probably seen this pattern:

ORM starts great for CRUD velocity
project grows
read paths get slower (N+1, over-fetching, accidental joins)
team starts rewriting "hot spots" in SQL
architecture becomes mixed anyway

So instead of asking "Which library wins?", ask:

"For this endpoint and this data shape, what is the cheapest and most predictable query path?"

The 5 metrics that actually matter

If you only track one metric (e.g., average response time), you will make bad decisions.

Measure these together:

p95 / p99 latency per endpoint
Query count per request (detect N+1 fast)
Rows + columns fetched (projection discipline)
Allocation rate / memory pressure (mapping overhead is real)
SQL transparency (how easy it is to inspect generated SQL)

When these 5 are stable, your persistence layer is usually healthy.

A practical architecture that works in real projects

I’ve had the best results with a hybrid approach:

ORM path for routine transactional CRUD and lifecycle-heavy writes
SQL-first path for read-heavy endpoints, reporting, and complex joins
Automated guardrails in CI (query count assertions, slow-query budget)

This removes ideology from the discussion and keeps both productivity and control.

Common anti-patterns (and cheap fixes)

1) "SELECT * everywhere"

Fix: Return only fields you need (DTO/projection), not whole entity graphs.

2) Hidden join explosions

Fix: Track query count per endpoint in tests.

3) Treating average latency as "good enough"

Fix: Watch p95/p99, not just average.

4) Framework-only tuning

Fix: Start with query shape + indexes first, framework tuning second.

What I changed in my own Java stack

In my recent work, I focused on:

explicit SQL visibility
type-safe mapping without stringly-typed glue
minimizing runtime "magic" for hot paths
reproducible benchmarks (code + methodology visible)

That led me to keep exploring lightweight, transparent ORM design in Ujorm3 and a small sample app (PetStore) that demonstrates the approach.

If you want context:

PetStore: Pure Java for UI and Safe SQL Mapping

Pavel Ponec — Thu, 02 Apr 2026 07:41:35 +0000

I would like to introduce the PetStore sample application, which demonstrates a pure "Java-first" approach to web interface development. The entire project is built on the idea of maximum type safety and clarity, achieved through two modules of the Ujorm3 library. These effectively eliminate common abstraction layers that often complicate development and debugging.

🛠️ Two Pillars of Ujorm3

1. UI Creation without Templates (ujo-web)

We have replaced traditional engines like Thymeleaf or JSP with pure Java code.

Type-safe rendering: HTML is generated using the HtmlElement builder and try-with-resources blocks. This approach allows writing Java code in a natural tree structure that faithfully mirrors the HTML structure.
Refactoring with full IDE support: Since the UI is defined in Java, everything you are used to works – autocomplete (IntelliSense), instant refactoring (e.g., extracting a table into a renderTable() method), and correctness checking while writing.
No more parameter errors: The HttpParameter interface uses enums to define web parameters. This practically eliminates typos in form field names, which in standard solutions only manifest at runtime.

2. Modern Database Handling (ujo-orm)

Forget about complex XML mapping or runtime errors in SQL queries.

Using Java Records: Standard Java records serve as domain objects (Pet, Category). They are naturally immutable, clean, and fully compatible with @Table and @Column annotations.
Type-Safe SQL Builder: An annotation processor generates metamodels (e.g., MetaPet) during compilation. The compiler catches an error in a column name, not an application crash in production.
SQL under control: No unexpected LazyInitializationException or hidden N+1 problems. You have absolute control over every SqlQuery. Moreover, you can easily map results from native SQL back to records using the label() method.

📁 Code Sample (PetServlet)

The project is designed with an emphasis on straightforwardness.
The following example from a stateless servlet demonstrates how elegantly logic, parameters, and HTML generation can be connected:

@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp) {
    var ctx = HttpContext.ofServlet(req, resp);
    var contextPath = req.getContextPath();
    var action = ctx.parameter(ACTION, Action::paramValueOf);
    var petId = ctx.parameter(PET_ID, Long::parseLong);

    var pets = services.getPets();
    var categories = services.getCategories();
    var petToEdit = Action.EDIT.equals(action)
            ? services.getPetById(petId).orElse(null) : null;

    try (var html = HtmlElement.of(ctx, BOOTSTRAP_CSS)) {
        try (var body = html.addBody(Css.container, Css.mt5)) {
            renderHeader(body, contextPath);
            renderTable(body, pets);
            renderForm(body, petToEdit, categories);
        }
    }
}

Here is what a native SQL query looks like in pure Java:

static final EntityManager<Pet, Long> PET_EM = 
             EntityManager.of(Pet.class);

public List<Pet> findAll() {
    var sql = """
        SELECT p.id AS ${p.id}
        , p.name    AS ${p.name}
        , p.status  AS ${p.status}
        , c.id      AS ${c.id}
        , c.name    AS ${c.name}
        FROM pet p
        LEFT JOIN category c ON c.id = p.category_id
        WHERE p.id >= :id
        ORDER BY p.id
        """;

    return SqlQuery.run(connection.get(), query -> query
        .sql(sql)
        .label("p.id", MetaPet.id)
        .label("p.name", MetaPet.name)
        .label("p.status", MetaPet.status)
        .label("c.id", MetaPet.category, MetaCategory.id)
        .label("c.name", MetaPet.category, MetaCategory.name)
        .bind("id", 1L)
        .streamMap(PET_EM.mapper())
        .toList());
}

💡 Why Choose This Approach?

This architecture represents an interesting alternative for developers who are tired of heavy JPA frameworks or bloated frontend technologies.

Where Ujorm PetStore shines most:

B2B and administrative applications: Where development speed and long-term maintainability are important.
Microservices: Thanks to minimal overhead and fast startup.
Projects with HTMX: It perfectly complements modern trends of returning to server-side rendering.

The "Java-First" philosophy drastically reduces context switching between Java, SQL, XML, and various templating languages.
Everything you need is under the protection of the compiler.

🚀 Try It Locally

The application utilizes the best of the current ecosystem:

Java 25
Spring Boot 3.5.0
H2 Database (In-memory)

All you need is JDK 25 and Maven installed, then just run:

mvn spring-boot:run

The application will start at http://localhost:8080.

Resources and Links:

PetServlet.java – A stateless Servlet acting as both Controller and View. It handles HTTP communication and builds the HTML.
Dao.java – Data access layer integrating Spring JDBC with Ujorm EntityManager.
Ujorm 3 Library on GitHub – Official library repository.
ORM Benchmarks – How this approach compares to the competition.

Does it make sense to you to have the UI and DB layers so tightly coupled with the compiler? I will be glad for any technical feedback!

Ujorm3: A New Lightweight ORM for JavaBeans and Records

Pavel Ponec — Mon, 23 Mar 2026 16:27:15 +0000

"Do the simplest thing that could possibly work."
— Kent Beck, creator of Extreme Programming and pioneer of Test-Driven Development.

I believe the Java language architects didn't exactly hit the mark when designing the API for the original JDBC library for database operations. As a result, a significant number of various libraries and frameworks have emerged in the Java ecosystem, differing in their approach, level of complexity, and quality. I would like to introduce you to a brand new lightweight ORM library, Ujorm3, which I believe beats its competitors with its simplicity, transparent behavior, and low overhead. The goal of this project is to offer a reliable, safe, efficient, and easy-to-understand tool for working with relational databases without hidden magic and complex abstractions that often complicate both debugging and performance. The first release candidate (RC1) is now available in the Maven Central Repository, released under the free Apache License 2.0.

The library builds on the familiar principles of JDBC but adds a thin layer of a user-friendly API on top of them. It works with clean, stateless objects and native SQL, so the developer has full control over what is actually executed in the database. Ujorm3 deliberately avoids implementing SQL dialects and instead uses native SQL complemented by type-safe tools for mapping database results to Java objects. It does not cache the results of any user queries. To achieve maximum speed, however, Ujorm3 retains certain metadata.

Application API Classes

The core class for database operations is SqlQuery (originally named SqlParamBuilder), which acts as a facade over PreparedStatement. The object supports named parameters for SQL statements, eliminates checked exceptions, and provides the result of a SELECT operation as an efficient Stream<ResultSet>. The mapping of data from a ResultSet to domain objects is then handled by a separate class called ResultSetMapper<DOMAIN>. Its instance prepares the mapping model upon first use and subsequently reuses it, which significantly reduces the overhead when processing a large volume of queries.

Mapping class attributes to database columns can be specified using annotations from the jakarta.persistence package (@Table, @Column, @Id), but the library can infer some properties even without them. Both mutable JavaBeans and immutable Records are fully supported. Ujorm3 only works with M:1 relations—1:M collections are intentionally omitted to prevent the generation of hidden queries and N+1 problems. Relational columns of a SELECT statement can be mapped using their labels in the format "city.name", which contain a dot-chained list of Java attributes of the domain objects. However, it is better to use a type-safe metamodel.

Automatically generated Meta* classes enable safe column mapping without the use of typo-prone text strings. The use of a SELECT statement can then look like this, for example:

static final ResultSetMapper<Employee> EMPLOYEE_MAPPER =
        ResultSetMapper.of(Employee.class);

void select() {
    var sql = """
            SELECT ${COLUMNS}
            FROM employee e
            JOIN city c ON c.id = e.city_id
            LEFT JOIN employee b ON b.id = e.boss_id
            WHERE e.id > :employeeId
            """;

    var employees = SqlQuery.run(connection(), query -> query
            .sql(sql)
            .column("e.id", MetaEmployee.id)
            .column("e.name", MetaEmployee.name)
            .column("c.name", MetaEmployee.city, MetaCity.name)
            .column("c.country_code", MetaEmployee.city, MetaCity.countryCode)
            .column("b.name", MetaEmployee.boss, MetaEmployee.name)
            .bind("employeeId", 0L)
            .streamMap(EMPLOYEE_MAPPER.mapper())
            .toList());
}

Please note that the domain class does not need to be registered anywhere in advance. For efficient work, however, I recommend creating a static mapper, whose implementation is prepared for multithreaded access. The column() method adds a database column with a label to the SQL template at the position of the ${COLUMNS} placeholder. An alternative label() method is also supported, allowing you to explicitly declare only column labels, thereby keeping the SQL query in the Java code closer to its native notation. However, these two approaches cannot be combined in a single query.

The EntityManager is used for working with entities, providing simple CRUD operations—including batch commands—through a Crud object. An interesting feature is the possibility of partial updates—the developer can specify an enumeration of columns to be updated, or pass the original object to the library, from which it will infer the changes itself. The mentioned classes are illustrated in a simplified class diagram. All listed methods are public:

Performance

Ujorm3 achieves very good results in benchmark tests, where it is compared with some popular ORM libraries. The mechanism of writing values to domain objects also contributes to the good score. Instead of the traditional approach using Java reflection, the library generates and compiles its own classes at runtime. Such an approach generally reduces memory requirements, minimizes overhead, and saves work for the Garbage Collector. The library has no dependencies on external libraries, and the compiled benchmark module (including the Ujorm3 library itself) is less than 3 MB, which is advantageous for microservices and embedded environments. However, it is good to keep in mind that in a production environment, in conjunction with slower databases, the differences in performance may partially blur.

Getting Started

To try the library in your Java 17+ project, simply add the dependency to your Maven configuration:

<dependency>
    <groupId>org.ujorm</groupId>
    <artifactId>ujo-core</artifactId>
    <version>3.0.0-RC1</version>
</dependency>
<dependency>
    <groupId>org.ujorm</groupId>
    <artifactId>ujorm-orm</artifactId>
    <version>3.0.0-RC1</version>
</dependency>

To automatically generate metamodel classes, add the optional APT configuration to the build element:

<plugins>
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.14.1</version>
        <configuration>
            <annotationProcessorPaths>
                <path>
                    <groupId>org.ujorm</groupId>
                    <artifactId>ujorm-meta-processor</artifactId>
                    <version>3.0.0-RC1</version>
                </path>
            </annotationProcessorPaths>
        </configuration>
    </plugin>
</plugins>

The Ujorm module from the Benchmark project can be used as a template for a sample implementation. The library's codebase is currently covered by JUnit tests that utilize an in-memory H2 database (in addition to mocked objects). Before releasing the final version, I plan to add integration tests for PostgreSQL, MySQL, Oracle, and MS SQL Server databases.

When to Choose the Ujorm3 Library?

If you are working for a corporate client expecting standards or portability of abstractions between databases, use JPA/Hibernate instead. If you have already found an ORM framework that meets your expectations and needs, stick with it. However, if you are looking for a fast and transparent alternative without hidden mechanisms for your new project, the Ujorm3 library is definitely worth a try.

Forem: Pavel Ponec

Native SQL in Java without JDBC boilerplate — meet Ujorm3

Fluent API

Named parameters instead of positional ?

No checked exceptions

Smart object mapping — including relations

Want compile-time safety? There's a metamodel for that.

Automatic resource management

There's more than just SqlQuery

SelectQuery in action

Performance

What this is NOT

Getting started

When does this make sense?

Ujorm3 is out: a tiny, type-safe ORM for JavaBeans & Records

Web Links

ORM library Ujorm 3.0 is released

Stop Debating ORM vs JDBC — Measure These 5 Things First (Java Guide)

Why teams get stuck in the same loop

The 5 metrics that actually matter

A practical architecture that works in real projects

Common anti-patterns (and cheap fixes)

1) "SELECT * everywhere"

2) Hidden join explosions

3) Treating average latency as "good enough"

4) Framework-only tuning

What I changed in my own Java stack

PetStore: Pure Java for UI and Safe SQL Mapping

🛠️ Two Pillars of Ujorm3

1. UI Creation without Templates (ujo-web)

2. Modern Database Handling (ujo-orm)

📁 Code Sample (PetServlet)

💡 Why Choose This Approach?

🚀 Try It Locally

Ujorm3: A New Lightweight ORM for JavaBeans and Records

Application API Classes

Performance

Getting Started

When to Choose the Ujorm3 Library?

Useful Links:

Named parameters instead of positional `?`

There's more than just `SqlQuery`

`SelectQuery` in action