700% higher concurrency is a link, the description says java25 and the README says java26, and the Maven row points at Gradle

700% higher concurrency is a link with query parameters, not a table

Four numbers carry the README, and they appear in both the header paragraph and a features table:

| Claim | Where it appears | |---|---| | 700% higher concurrency | header and cost performance row | | 50% memory savings | header and cost performance row | | 10x faster startup | header, and the productivity row calls it faster debugging | | Pack 90% smaller | header and deployment row |

The only reference offered for the concurrency figure is a link into the TechEmpower benchmark results, and the link carries its own filters in the address: a hardware profile, the plaintext test and a result section identified as data-r23.

That is a pointer to somebody else's table rather than a reproduction of one. No competing framework is named, no machine is described, and no local figure is printed next to the ratio. The memory and packaging figures have no reference at all, and the startup figure changes meaning between the two places it appears, being a deployment benefit in one and a debugging benefit in the other. All four are stated as ratios, so a reader has nothing to check them against except the linked page.

The repository description says java25 and the README says java26

The supported Java range is stated three ways, and the base implementations do not cover all of them.

The repository description says Compatible with java8 ~ java25. The README header says it also supports java8 ~ java26, native runtime, and the compatibility row of the features table repeats java8 ~ java26 with graalvm native image. The companion repository table lists two base implementations, opensolon/solon-java17 described as base java17 and opensolon/solon-java25 described as base java25. There is no java26 repository in that table.

So the highest number claimed in prose has no matching artifact listed, and the artifact that does exist stops one release lower.

The same description carries two other things worth reading closely. One is a parenthetical at the end, Replaceable spring, which is the only place in the repository that names a competing framework. The other is a spelling: the description lists the project's own adjectives as Restrained, Efficient, Open, Ecologicalll, with the last word carrying three letter l where the other three carry none.

The Maven plugin row links to the Gradle plugin repository

The companion repository table is the most useful map the project publishes, and it has at least one wrong cell. The row for the Solon Maven plugin carries the path opensolon/solon-gradle-plugin, so both the Maven row and the Gradle row point at the same repository.

The rest of the table is more careful. The framework itself is opensolon/solon, and opensolon/solon-examples is described as the official website supporting sample code repository, which is an unusual name for it to carry and explains why the demos link points at Gitee. Then come solon-ai, solon-flow, solon-expression, solon-cloud, solon-admin and solon-integration, all labelled only as code repositories, followed by the two base implementations, the two build plugins, and the IDE plugins for IntelliJ and VS Code.

Two rows in the table are empty and used as spacers, which is how the groups are separated visually.

The Sonatype badge at the top of the README searches for org.noear:solon-parent, which matches the solon-parent directory in the repository root and fixes the group identifier as org.noear for everything the project publishes.

Four READMEs are linked from the switcher and a fifth sits in the tree

The language line offers four choices: English, 中文, Русский and 日本語, pointing at README_CN.md, README_RU.md and README_JP.md.

The root directory holds five readme files: README.md, README_CN.md, README_EN.md, README_JP.md and README_RU.md. README_EN.md is not the target of any link in the switcher, and the current file at README.md is the one being read as English. So there are two files claiming the English version, one of which nothing points at.

That is a small thing on its own, and it matters more because of what sits beside it. The root also carries UPDATE_LOG.md plus UPDATE_LOG_v1.md, UPDATE_LOG_v2.md and UPDATE_LOG_v3.md, one changelog per earlier major version, and three separate upgrade notes named V2.0.md, V3.0.md and V4.0.md. Project history is maintained as a pile of files in the main repository rather than as release notes attached to tags, and the release titles themselves are plain, Solon v4.1.1 and Solon v4.1.0.

soloncode and solonclaw are Java 8 ports of two named tools

Two rows of the companion repository table are not part of the framework at all, and they are grouped separately from everything above them.

opensolon/soloncode is described as the Java8 impl version of Claude Code, and opensolon/solonclaw as the Java8 impl version of OpenClaw. Both are Java 8 implementations of tools that are not otherwise part of this project, which puts them in the same category as a downstream integration rather than as an extension of the framework.

The naming is what makes them worth a second look. A repository called soloncode reads as part of the framework family until the description says otherwise, and the same goes for solonclaw. Nothing in the README explains why a Java 8 baseline applies to ports of these two particular tools, while the framework itself is described as covering java8 through java26.

What the README offers instead of an architecture description is a diagram section with two bullet labels, solon and solon cloud, and two schema images at the repository root named solon_schema.png and solon_cloud_schema.png. The ecosystem picture is therefore two diagrams and a table, with the table doing most of the work.

The root carries Maven settings, notice templates and three code trees

The top level of the repository is where the build and legal machinery sits, and several entries there are unusual for a framework root.

There is a settings.xml and a repository.xml, so the Maven configuration travels with the source rather than living on a developer machine. There is NOTICE-license-mappings.xml and a NOTICE.template, which is the pair a multi-module build needs to assemble third party license notices, and that matters here because the framework pulls in a wide dependency set across a dozen published artifacts.

The code itself is split into four trees: solon-parent, solon-projects, solon-shortcuts and solon. Alongside them are three directories whose names begin with a double mark, __hatch__, __release__ and __test__, and the README points its unit test link at __test/ directly, so the test project is part of the main repository rather than a separate one. A www_validate directory and a style directory handle the website, .editorconfig handles whitespace, and .gitee/ and .github/ mean the project is mirrored onto two hosting services with parallel issue trackers.

The license is Apache-2.0, and it is one of the few entries here that needs no interpretation.

Samples, documentation and user cases all live in other repositories

What this repository does not contain is most of what a reader would use it for. The documentation is the website at solon.noear.org, the runnable samples are in opensolon/solon-examples, and the user cases are article pages on that same site, one for open source projects and one for business projects.

The README also links a DeepWiki page for the project and thanks JetBrains for supporting open source projects. The demos link points at the Gitee mirror of the examples repository rather than at GitHub, which is consistent with the mirror arrangement: the repository table itself points at the examples repository through relative paths, and the star badges at the top of the README are duplicated across Gitee, GitHub and GitCode.

So the framework, the samples, the documentation and the issue tracker are four different places, and a contributor has to know which one a question belongs to. The main repository's own contribution guide is a single CONTRIBUTING.md at the root, with no per-module instructions visible from the tree.

Three releases in seven weeks and the last push matches the tag

The release history is regular enough to read as a schedule. v4.0.6 was published on 2026-08-17, v4.1.0 on 2026-09-07 and v4.1.1 on 2026-10-01, three releases in seven weeks, with the minor version moving from 4.0 to 4.1 in the middle of that run.

The most recent push to the default branch main is dated 2026-10-01T01:24:41Z, and the v4.1.1 release carries the same timestamp. A tag cut in the same commit as the branch head means the published artifact and the tip of main are the same tree at the moment of the release, which is the tidiest possible arrangement and the reason there is no gap to reconcile.

The version scheme is plain four part numbering with a major line that has already been through four, and the upgrade notes for the three earlier jumps are kept as V2.0.md, V3.0.md and V4.0.md in the repository root rather than attached to the tags they describe. Someone arriving from version 3 has a file to read; someone arriving from a nightly build of 4.1.0 has the release titles and the update log.

Editorial conclusion

Solon fits a Java team that wants a lightweight non-Jakarta runtime with a plugin ecosystem already split into separate repositories, and the ecosystem table is the fastest way to see the shape of it. Four things to check before adopting it. The headline numbers are ratios with a single benchmark link behind them and no baseline named. The supported Java range is stated two different ways, in the repository description and in the README, and the base implementation repositories stop at java25. The Maven plugin row in the repository table links to the Gradle plugin repository, so the table has at least one wrong cell. And the documentation is split across a website, a separate sample repository and four language READMEs, one of which duplicates the current file. Releases land roughly monthly, with v4.1.1 published on 2026-10-01 in the same commit as the branch push.

Frequently asked questions

Official sources

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