# SpringBootCodeGenerator: Java CRUD scaffolding you can edit

> A Spring Boot 3 and Freemarker application that reads DDL, INSERT or SELECT statements and a JSON blob, then emits JPA, MyBatis, MyBatis-Plus, BeetlSQL, CommonMapper or plain JdbcTemplate output as a downloadable ZIP. The templates are files in the repository, which is the whole appeal and the whole constraint.

**moshowgame/SpringBootCodeGenerator** — Also known as Dalanggou Code Generator, a Java code generator based on Spring Boot 2 and Freemarker, built to automate boilerplate. Supports MySQL, Oracle and PostgreSQL, generating JPA/JdbcTemplate/MyBatis/MyBatis-Plus/BeetlSQL code from DDL SQL statements.

- Repository: https://github.com/moshowgame/SpringBootCodeGenerator
- Website: https://zhengkai.blog.csdn.net
- Stars: 2,205 · Forks: 720
- Language: Java
- License: MIT
- Published: 2026-10-08 · Updated: 2026-10-08 · Language: en
- Canonical page: https://hysenlabs.com/projects/moshowgame-springbootcodegenerator

## Reading SQL instead of introspecting a live database

Most code generators want a database connection and reflect over existing tables. This one takes text. The README lists four input modes: DDL SQL mode, which generates code from table creation statements, INSERT SQL mode for insert statements, SELECT SQL mode for query statements, and JSON mode for simple JSON data.

That choice has real consequences. You do not need credentials, a reachable database, or a schema that matches production, which makes the tool usable on a laptop with no database running and in a review process where handing over credentials is awkward. The cost is that parsing quality becomes the product. The technology stack named in the README is Spring Boot 3, Freemarker as the template engine, FastJSON2, JSqlParser as the SQL parser, and Lombok as the boilerplate tool.

JSqlParser doing the SQL work is the load-bearing choice here, and it is also the boundary. Parsing arbitrary SQL well is an ongoing problem in that library, and a generator that inherits its gaps will misread a dialect feature it does not understand. The March 2025 release notes record exactly this class of bug: a fix for uppercase SQL types that could not be converted, credited to a contributor's feedback, alongside NewUI V2 frontend work and fixes to the JPA templates for the case where Lombok is switched off.

The databases named are MySQL, Oracle and PostgreSQL, and the generated output targets JPA, JdbcTemplate, Mybatis, MybatisPlus, BeetlSQL and CommonMapper, with TkMyBatis, Element UI and Bootstrap UI also listed as templates.

## Clone, compile, run on port 1234

The startup section of the README is short and complete:

```bash
git clone https://github.com/moshowgame/SpringBootCodeGenerator.git

cd SpringBootCodeGenerator
mvn clean compile
mvn spring-boot:run

http://localhost:1234/generator

mvn clean package -DskipTests

mvn test
cd /target/site/jacoco
```

Port 1234 is the detail to notice, since it is not a default anywhere in the Spring ecosystem and the URL includes the `/generator` path rather than the bare root. The packaging line deliberately passes `-DskipTests`, and the test line that follows runs `mvn test` and points at a JaCoCo report under the target directory, so the project does have unit tests and coverage output even though the packaged build skips them.

The repository tree also contains `@install.cmd` and `@run.cmd`, which are Windows batch files, and the README has an author section that points at a CSDN blog. Neither is mentioned in the quick start, so the documented route is the Maven route.

The project is MIT licensed, its primary language is recorded as Java, and its topics are `code-generator`, `crud`, `freemarker` and `springboot2`. It is not archived, and the last push was on 2026-09-09.

## Spring Boot 3 on master, Spring Boot 2 on the jdk11 branch

The repository description is out of date, and the rest of the project is not, so this is worth laying out plainly.

The GitHub description for this repository says the project is based on SpringBoot2 and Freemarker, and one of the four topics is `springboot2`. The README, by contrast, describes a code generation platform built on SpringBoot3 and Freemarker, the technology stack section lists Spring Boot 3, and the README also describes a 2025 rewrite with a Controller-Service-DTO-VO layered structure, interface and implementation separation in the service layer, and a strategy pattern for handling different SQL parse types.

The April 2024 release resolves which is which by naming three branches. Master is the main branch, based on SpringBoot3 and requiring JDK17 or newer. The `jdk11` branch is the compatibility branch, based on SpringBoot2, supporting JDK8, JDK11 and JDK17, and the release notes are explicit that compatibility is better but maintenance is slower, which is why it exists for older machines and older environments. The third branch, NewUI, is described as a new UI interface redesign.

So both descriptions are partly right about different branches, and the practical instruction is short: default branch means Spring Boot 3 and JDK 17 or newer, and anyone on an older JDK should switch to the `jdk11` branch before building. The 2024-04-20 entry is also where the CDN change appears, moving the static resource host to `cdn.staticfile.net` after the old `cdn.staticfile.org` domain failed, with the local version unaffected.

## Configuration defaults that shape every generated file

A code generator is mostly a set of defaults, so the configuration table is the most informative part of the README. The defaults listed include an author name, a package name of `cn.devtools`, `Return.SUCCESS` and `Return.ERROR` wrappers for successful and failed responses, an `ignorePrefix` of `sys_`, an input type of `DDL SQL`, a tinyint conversion to `int`, a time type of `Date`, camel case naming, package wrapping turned on, Swagger UI turned off, field comments turned on, and Lombok turned on.

Two of those defaults will shape almost every file you generate. `ignorePrefix` set to `sys_` means a column named `sys_status` does not become a field named `sysStatus`, which is the kind of convention that saves a lot of manual cleanup. And `nameCaseType` of camel case controls whether a table named `t_user_info` produces a `UserInfo` class rather than a literal `TUserInfo`.

The README documents a way to escape the built-in special characters in templates, noting that `#` can be replaced with one currency symbol and `$` with another, which matters if your identifiers contain those characters. There is also a toggle for local versus CDN static resources, and options for automatic package imports and for whether the package path is included.

The template variables available inside a `.ftl` file are a short list and worth knowing before editing anything: `tableName` for the table name in SQL, `className` for the Java class name, `classComment` for the SQL table comment or Java class comment, `fieldName` for a field name, and `fieldComment` for a field comment. A custom template is added in three steps: find the matching type under `resources/templates/code-generator`, copy and edit a Freemarker `.ftl` file, then edit `template.json` to register it.

## One-click ZIP download and what it puts in the archive

The most concrete recent addition is ZIP packaging. A separate download button next to the generate button takes everything produced in one run and packs it into a ZIP grouped by template, so you are not copying files one at a time. The README documents the endpoint and the naming rules.

```
POST /code/generate-zip
Content-Type: application/json
```

The request body is the same as for `/code/generate`, and the response is an `application/zip` byte stream with a `Content-Disposition` header carrying both a plain `filename` and an RFC 5987 `filename*` encoded value.

That double header is the detail that shows care. The plain `filename` parameter is what old clients and some Windows paths will read, while the `filename*` form is what carries UTF-8 encoded names correctly, and shipping both is the standard way to avoid mojibake in archive names.

File naming is templated rather than inferred. You add a `fileName` field for a template entry in `src/main/resources/template.json` and can use placeholders such as `${className}` and `${tableName}`:

```json
{
  "id": "20",
  "name": "controller",
  "description": "controller",
  "fileName": "${className}Controller.java"
}
```

If `fileName` is left empty, the suffix is inferred from the template's `group` and `name`. The README lists the resulting archive layout with directories for each persistence layer, plus `ui/` and `sql/`, and notes that duplicate filenames are automatically deduplicated with a sequence number such as `UserInfo_1.java`. The implementation adds no dependency for this: it uses the JDK's own `ZipOutputStream`.

## What this generator will not decide for you

The honest limitation is that the output is a starting point, not a design. A generated CRUD stack gives you an entity, a mapper or repository, a service, a controller and often a UI page, and every one of those files encodes opinions about naming and structure that came from templates written by one person. If your project uses a different layering convention, the generator saves less than it appears to.

This is not a criticism so much as the shape of the category. The value is highest in the first minutes of a new module, when the structure is familiar and the value of a directory layout is that you do not have to invent one. It drops sharply when the module has unusual requirements, because then you are fighting the template rather than using it.

The comparison with the alternatives is worth making directly. An IDE plugin such as the one for IntelliJ or Eclipse generates code from a live database connection with a schema-aware model, which is more accurate when you have a database to connect to and less useful when you do not. This project wins on not needing credentials and on producing a whole archive at once. It loses on not introspecting an actual schema, and on dialect handling, which it delegates to JSqlParser.

There is also a matter of what a ZIP is good for. Generated code enters your repository as ordinary files that you then own, edit and review. That is the right property for generated code. It also means the templates are the only thing you configure once, and everything else is a diff you are responsible for.

## Where the 2025 rewrite left the project

The README documents a rewrite in 2025 that modernized the structure on top of the existing foundation, and it lists five changes. The layering is Controller-Service-DTO-VO with defined responsibilities per layer. Interfaces and implementations are separated in the service layer to make testing and extension easier. A strategy pattern handles different SQL parse types so new parse methods can be added. The project follows Spring Boot and Java development conventions. And exception handling is unified through a global mechanism.

The restructured tree is shown in the README and is ordinary Spring Boot, rooted at `com.softdev.system.generator`. `GeneratorApplication.java` is the entry point, a `config/` package holds `WebMvcConfig.java` for MVC configuration and `GlobalExceptionHandler.java`, and a `controller/` package holds `PageController.java` for page routing, `CodeGenController.java` for the code generation endpoints and a template controller.

Two project-level facts are easy to miss. The project grew out of a codebase started in 2018, and the README says so directly, which is useful context for judging how much of it predates current Spring Boot practice. And the repository is described as MIT licensed, so generated code carries no obligation back to the project.

For someone deciding whether to use it, the practical sequence is short. Build master with JDK 17 or newer, generate from a real table, then read the templates for the layers you care about before generating a second time. If the second round of edits is smaller than the first, the tool is paying for itself.

## Conclusion

SpringBootCodeGenerator earns its place when you are starting the same kind of Spring Boot module for the fourth time and want a starting structure rather than a finished design. It will not generate the layer where your actual difficulty lives, because the templates are deliberately generic and the real work is in `template.json` and the `.ftl` files. Note that the repository description still says SpringBoot2 while the default branch is Spring Boot 3 requiring JDK 17 or newer, with a separate `jdk11` branch for Spring Boot 2 users, so pick your branch before you clone. Start with `mvn clean compile` and `mvn spring-boot:run`, open the generator page on port 1234, and rewrite the controller and service templates first, since those are the two you will edit first in every project anyway.

## FAQ

### How do I run SpringBootCodeGenerator locally?

Clone the repository, run `mvn clean compile` and then `mvn spring-boot:run`, and open `http://localhost:1234/generator`. Packaging without tests is `mvn clean package -DskipTests`, and the JaCoCo coverage report is written under the target site directory.

### Which Java and Spring Boot version does the master branch need?

The April 2024 release notes state that master is based on SpringBoot3 and requires JDK17 or newer. A separate `jdk11` branch based on SpringBoot2 supports JDK8, JDK11 and JDK17 for older environments, with the notes describing compatibility as better but maintenance as slower.

### What input can SpringBootCodeGenerator read?

Four input modes are documented: DDL SQL for table creation statements, INSERT SQL, SELECT SQL, and simple JSON data. No database connection is required, since parsing is handled by the JSqlParser library named in the technology stack.

### Which persistence templates does it generate?

JPA, MyBatis, MyBatis-Plus, BeetlSQL, CommonMapper, TkMyBatis and JDBC Template, plus frontend UI templates such as Element UI and Bootstrap UI. MySQL, Oracle and PostgreSQL are the databases named as supported.

### How do I add my own template?

Find the matching type under `resources/templates/code-generator`, copy and edit a Freemarker `.ftl` file, then modify `template.json` to register it. Templates can use variables including `tableName`, `className`, `classComment`, `fieldName` and `fieldComment`.

### What license is SpringBootCodeGenerator released under?

MIT. Generated code is yours to edit and own, and the project itself carries no requirement on what you do with the output beyond the license terms of the templates you copy.

## Sources

- [License: MIT](https://github.com/moshowgame/SpringBootCodeGenerator/blob/master/LICENSE)
- [moshowgame/SpringBootCodeGenerator on GitHub](https://github.com/moshowgame/SpringBootCodeGenerator)
- [Project website](https://zhengkai.blog.csdn.net)
- [README](https://github.com/moshowgame/SpringBootCodeGenerator/blob/master/README.md)
- [Releases](https://github.com/moshowgame/SpringBootCodeGenerator/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/moshowgame-springbootcodegenerator