JeecgBoot: AI-generated Java CRUD that ends in a hand merge

The generation loop ends with a hand merge, so you own the divergence

The stated development mode is a sequence: AI generation, then online configuration, then code generation, then a manual merge, with an AI modification step after it. Read in order, it is a description of where a human stays in the loop. A natural language description produces the table, the CRUD code and the menu permissions, and a developer decides what to keep. AI Skills extends the same loop into flow diagrams, form design, reports and dashboards, with a one-click install path for Claude Code plus JEECG Skills at help.jeecg.com/java/ai/skills/skill-install.

The cost of that design is ownership. Once the output is merged it is your code, with no generator version stamped in it and no upgrade path when the templates improve, so a repository leaning on generated CRUD accumulates a private layer over time. Nothing in the repository documents a regeneration or diff workflow, so a team adopting it has to write its own rule for when to regenerate a screen and when to hand-edit it forever.

The three efficiency claims contradict each other

The repository description promises removal of 90 percent of the repetitive work in a Java project. The introduction says 80 percent. Two later sections say 70 percent. All three figures sit in the same documentation, which is the reason to discount all three. None is tied to a measured codebase, a time comparison or a specific task, and the cost of the platform is stated plainly elsewhere in the same text: generated code has to be merged by hand.

What you can test sits elsewhere in the documentation. The generator covers single-table, tree-table, one-to-one and one-to-many models, and the query filter appends conditions to the SQL the backend builds, with exact, fuzzy, contains and does-not-match matching. Those are claims you can check against a real module in an afternoon. The percentage is not something a team can check before committing to it.

Two compose files, one codebase, and a frontend on its own network

docker-compose.yml runs the monolith. MySQL is built from ./jeecg-boot/db, Redis is pulled from a Hangzhou registry mirror, the application is built from ./jeecg-boot/jeecg-module-system/jeecg-system-start, and an nginx frontend is built from ./jeecgboot-vue3. docker-compose-cloud.yml with start-docker-compose-cloud.sh and .bat covers the microservice layout, and check_jeecgenv.py sits in the root with no documented invocation.

The startup ordering is the part worth copying. The application container does not sleep. The compose file gates it on the other two services reporting healthy:

  jeecg-boot-system:
    build:
      context: ./jeecg-boot/jeecg-module-system/jeecg-system-start
    restart: on-failure
    depends_on:
      jeecg-boot-mysql:
        condition: service_healthy
      jeecg-boot-redis:
        condition: service_healthy
    ports:
      - 8080:8080

MySQL is given a 60 second start period before its retries begin, and Redis is checked with a plain ping. The quirk sits on the frontend. It is attached to a network named jeec while all three backend services sit on jeecg-boot, so a container-name reference from nginx to the API would not resolve across them. The file does not show how the frontend reaches the backend, and that omission is the first thing to read when the UI loads but the API calls fail.

admin/123456 and MYSQL_ROOT_PASSWORD: root ship in the repository

The documented default login is admin/123456. The database container in docker-compose.yml is built with a root password of root, and the MySQL user is allowed from any host with the port published to 13306 on the host interface:

    environment:
      MYSQL_ROOT_PASSWORD: root
      MYSQL_ROOT_HOST: '%'
      TZ: Asia/Shanghai
    command:
      - --character-set-server=utf8mb4
      - --collation-server=utf8mb4_general_ci
      - --explicit_defaults_for_timestamp=true
      - --lower_case_table_names=1
      - --max_allowed_packet=128M
      - --default-authentication-plugin=caching_sha2_password
    ports:
      - 13306:3306

The wait before the application starts is measured rather than guessed, and the healthcheck that decides it carries the same credential:

    healthcheck:
      test: ["CMD-SHELL", "mysqladmin ping -h127.0.0.1 -uroot -proot --silent"]
      interval: 10s
      timeout: 5s
      retries: 12
      start_period: 60s

Nothing in the repository documents a first-login step that forces a password change, so a deployment reachable beyond a laptop has a known administrator credential before anyone configures anything. Change both values before the first run on a machine with an address other people can reach, and keep 13306 off the public interface.

The mobile app and the starter pack are separate repositories

The project table describes four things: the jeecg-boot backend, the jeecgboot-vue3 frontend, the jeecg-uniapp app framework, and the jeecg-boot-starter pack. Only two of them are in this repository. The root holds jeecg-boot/, jeecgboot-vue3/, the two compose files, four start scripts, check_jeecgenv.py and four localized readme files. jeecg-uniapp and jeecg-boot-starter are linked out as projects of their own.

That split is the practical cost of assembling a stack. The app client and the starters move at their own pace, and nothing in the compose file pins a version for either. The starter pack is where the infrastructure features live, named as microservice startup, xxljob, distributed locks, RabbitMQ, distributed transactions and ShardingSphere sharding. A team that wants any of those tracks a second repository and has to decide for itself when a starter release matches the platform it plugs into.

Generated SQL and menu permission rows arrive with the code

For each data model the generator emits front end code, back end code, the table-creation SQL and the menu permission entries, and the output is meant to run as generated. Four model shapes are named: single table, tree table, one-to-one and one-to-many. The generated CRUD also carries Excel import and export, including a one-to-many export mode, so a data model choice made at generation time shows up in the import layer later.

Two of the four outputs change state outside your editor, and neither is checked by the compiler. The SQL creates tables, and the menu rows are what the button and data permission system later reads, which means a generated screen arrives with an authorization grant attached to it. Nothing documents a rollback for a generated model, so the safe first run of any template is against a scratch database. Custom templates are supported, though the count is stated loosely: four template styles are claimed, while the breakdown in the same line lists two single-table, one tree-model and three one-to-many sets.

Row and field permissions make one login useless for testing

Access control is described at three granularities: button, data and form field. Data permission is said to reach row level, list level and form field level, so two people opening the same page can see different rows and can edit different fields on the same row. The query filter generates itself and appends matching conditions to the SQL the backend builds, supporting exact, fuzzy, contains and does-not-match matching.

The testing consequence is specific. A single admin login tells you nothing about whether the data rules work, because the admin sees everything. Verifying this platform needs at least two accounts with different roles looking at the same page, plus one row they deliberately disagree about. A report that says a list shows too much is only actionable if it names the role, and the default admin/123456 credentials make it easy to file exactly that report without ever leaving the admin view.

The AI layer defaults to DeepSeek and leaves credentials undocumented

The platform ships an AI application module that the project compares to Dify, combined with a knowledge base question-answering system built on large language models and RAG. The named pieces are model management, knowledge base management, document parsing, vector database connection, RAG pipelines, flow orchestration, MCP and plugins, with a separate README-AI.md holding the detail. ChatGPT, DeepSeek and Ollama are named as compatible, and the current version is said to default to DeepSeek.

Two things follow from that list. The model is a deployment decision with a data path attached, since document parsing and retrieval send business content to whichever provider you configure, and the on-premises option in the list is Ollama rather than the hosted defaults. The repository also does not document where model credentials are stored, so a team handling keys has to read the deployment guide instead of the source. Native-stack coverage is stated more concretely: Dameng, Kingbase and TiDB for databases, TongWeb, TongRDS, AppServer and CacheDB for middleware, and Kylin operating systems on the grounds that they are Linux-kernel based.

Editorial conclusion

JeecgBoot fits a Java team that wants CRUD, permissions and menus scaffolded from a data model and accepts owning the merge afterwards. It does not fit a team that wants a finished application with no source-level work, because the pipeline stops at a hand merge and nothing upstream later updates the code you kept. Before adopting, change the admin/123456 login and the MYSQL_ROOT_PASSWORD: root value in docker-compose.yml, then run one generated model against a scratch database to see what the table SQL and menu rows actually do.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes