MyBatis Generator: generating Java and Kotlin data access code from a live schema

The boilerplate MyBatis Generator removes, and the projects it fits

Every MyBatis project starts the same way: a table exists, and someone writes a mapper interface, an XML mapper, and a record class that mirrors the columns. The README describes the tool's purpose plainly: it "will introspect a database table (or many tables) and will generate artifacts that can be used to access the table(s)." The stated goal is narrower than "generate your persistence layer." MBG "seeks to make a major impact on the large percentage of database operations that are simple CRUD (Create, Retrieve, Update, Delete)." That sentence is the honest scope statement. If your workload is dominated by single-table reads and writes keyed on a primary key, the generator writes code you would otherwise write by hand, repeatedly, for every table.

The audience follows from that. Teams on MyBatis who are adding tables faster than they are adding query logic. Projects where the schema is the source of truth and the Java classes are downstream of it. The topics list on the repository names both java-8 and kotlin, and the README confirms MBG "can generate code for Java based projects, or for Kotlin based projects." It is not a general ORM and does not try to be. It produces MyBatis artifacts, which means the generated code is only useful if you have already chosen MyBatis as your mapper framework.

Introspection, runtimes, and what actually lands in your source tree

The mechanism is introspection, not code analysis. MBG connects to a database, reads table metadata, and writes files. There is no annotation processor and no compile-time hook. The repository layout reflects this: the work lives in core/, with a separate eclipse/ directory for the IDE feature, so the same engine backs the command line, the build plugins and the Eclipse integration.

The README uses the word "runtimes" for the output styles. This is the part that trips people up on upgrade. The generated code is not version-neutral: it targets a particular MyBatis runtime, and the code MBG emits for one runtime will not necessarily compile against another. The README does not enumerate the runtimes or map them to MyBatis versions, and it does not document what changes between them. That silence matters more than it looks, because the generator writes source files into your project, and those files then live under your version control and your review process.

A second design consequence: the generated classes are yours to keep. Nothing regenerates them at runtime. If a column is renamed, the code does not adapt until you rerun the generator, and when you rerun it the tool rewrites files that may already contain your edits. The README does not document a merge strategy or a rollback path. Treat generated output as build artifacts with an agreed ownership rule before the first run, not after.

Installing MyBatis Generator and generating against one table

The README points at a dedicated page for invocation methods and says MBG "can be run in multiple ways - from the command line, with an Ant task, as a Maven plugin, etc." It does not reproduce those steps, so the honest starting point is that page plus the Maven Central coordinates shown in the README badge: org.mybatis.generator:mybatis-generator.

The Maven plugin is the path most build-driven teams take. The README does not give the plugin block, so check the running page for the current plugin coordinates and goal names rather than copying a version from a blog post. What you will write yourself is the configuration file. The README does not print a sample of it, so treat the file as something you assemble from the running page rather than something you paste from here.

The context element is where the runtime style is chosen, and the table elements are an allowlist: anything not named is not touched. That is the single most useful safety property of the tool, and it is the one people forget. Scope the table list deliberately instead of pointing the generator at an entire schema on the first run.

For Eclipse users there is a separate route. The README gives three install options: the Eclipse Marketplace entry at https://marketplace.eclipse.org/content/mybatis-generator, a direct update site at https://jeffgbutler.github.io/mybatis-generator-update-site/, or a zip from the GitHub releases page at https://github.com/mybatis/generator/releases. Pick one; installing from the marketplace and then also adding the direct update site is a good way to end up with two copies of the feature.

Where the generator stops being the right tool

The limitation is built into the premise. A tool that optimizes for simple CRUD has nothing to say about the rest of your query surface. Multi-table joins, window functions, recursive CTEs, bulk upserts and reporting queries are hand-written work regardless of whether MBG generated your record classes. You can use both, but the generated artifacts will not cover that ground, and the project never claims they will.

The sharper failure mode is regeneration against a moving schema. Because the output is source code committed to your repository, a rerun after a column change produces a diff that a reviewer has to read. If someone has added a method to a generated record class, that method is a candidate for silent loss. The README does not describe what happens to hand-edited generated files. Decide the rule up front: either generated files are never edited, or they live in a directory excluded from review, and the second option costs you the ability to see schema drift in a pull request.

There is also a fit problem with existing domain models. If your application already has rich entity classes with behaviour, validation and relationships, MBG's generated records will be a parallel representation of the same tables. Two models for one table is a maintenance cost that no generator removes.

MyBatis Generator against hand-written mappers and JPA tooling

The obvious alternative is writing the mappers yourself. The difference is not quality, it is timing and consistency. A hand-written mapper lets you shape the SQL exactly, including the join-heavy queries MBG will not produce, and it never surprises you with a diff. The cost is that every new table means new files, and the files look slightly different depending on who wrote them. MBG trades that variation for a fixed shape and a regeneration step.

A second comparison is against JPA-based code generation, where the entity is the centre of the model and the framework derives queries from it. MBG inverts that: the table is the centre, and the generated code is a thin access layer over it. That inversion is why MBG output is easy to read and hard to abstract over. If you want a repository abstraction with derived query methods, MBG is the wrong shape. If you want SQL you can see in an XML mapper and a record class that matches the columns, it is the right one.

A third option is generating only part of the work. Nothing in the tool forces all-or-nothing adoption; the table allowlist means you can generate the twenty boring lookup tables and hand-write the five that carry real query logic. That is probably the most common sensible configuration, and the README's emphasis on simple CRUD supports it.

Release cadence, licence, and the cost of regenerating

The repository is not archived, and the last push was on 2026-09-19. The release history shows a long quiet stretch: 1.4.1 in March 2022, 1.4.2 in February 2023, then 2.0.0 on 2026-04-08. That gap is the relevant maintenance fact. A major version after a three-year silence usually means the runtime styles and the minimum Java or MyBatis version moved, and the README does not describe the migration. If you are on 1.4.x, read the 2.0.0 release notes before upgrading, and expect generated code to change shape rather than to compile untouched.

Upgrade cost is concentrated in one place: the generated files. Because they are checked in, a version bump produces a large diff across every table. The practical mitigation is to keep the generator configuration and the generated output in a module or directory you can regenerate and diff in isolation, so the upgrade is a reviewable commit rather than a change tangled with feature work.

The licence is Apache-2.0, per the LICENSE file and the README badge. That is a permissive licence with an explicit patent grant, and it does not impose copyleft obligations on the code you generate or the application around it. This is a description of the licence text, not legal advice; if your organisation has a policy on generated code provenance, route the question through it rather than through this article.

Editorial conclusion

Adopt MyBatis Generator when your project is Java or Kotlin on MyBatis, your schema is stable enough to regenerate against, and most of your data access is simple CRUD. Do not adopt it when your queries are mostly hand-written joins and reporting SQL, or when the generated classes would fight an existing domain model. Before committing, verify which runtime style matches your MyBatis version, confirm the generator configuration targets the right tables rather than the whole schema, and check that the generated code compiles against the MyBatis dependency you actually ship.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. mybatis/generator on GitHub
3. Project website
4. README
5. Releases