# Solon: a Java framework that swaps Spring for a smaller runtime

> Solon is an Apache-2.0 Java application framework built as a non-Java-EE alternative to Spring, with its own container and a wide Java version range. This article covers how it is structured, where it does not fit, and what the README leaves unsaid.

**opensolon/solon** — Java enterprise application development framework for full scenario: Restrained, Efficient, Open, Ecologicalll!!! 700% higher concurrency 50% memory savings Startup is 10 times faster. Packing 90% smaller; Compatible with java8 ~ java25; Supports LTS. (Replaceable spring).

- Repository: https://github.com/opensolon/solon
- Website: https://solon.noear.org
- Stars: 2,793 · Forks: 287
- Language: Java
- License: Apache-2.0
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/opensolon-solon

## What Solon is and who it is written for

Solon is a Java enterprise application development framework distributed under Apache-2.0. The README describes it as being for full scenario and lists four properties: restrained, efficient, open, and ecological. The framing that matters more than the adjectives is the parenthetical in the repository description: Replaceable spring. Solon is aimed at teams writing Java web services and enterprise applications who want an application container that is not built on Java EE or Jakarta EE, and who are willing to leave the Spring programming model behind.

The intended audience is narrower than the tagline suggests. The project ships its own container, its own configuration binding, and a set of companion repositories (solon-cloud, solon-ai, solon-flow, solon-expression, solon-admin, plus Java 17 and Java 25 baseline forks). Someone evaluating Solon is not choosing a library to drop into an existing Spring Boot service. They are choosing the framework that owns the application lifecycle, and the migration cost of reversing that decision is the whole application.

Java version coverage is the most concrete differentiator stated in the README: java8 through java26, with GraalVM native image support. The repository also carries separate solon-java17 and solon-java25 code repositories for those baselines. That range is unusual. Most modern Java frameworks have moved their floor upward, so a team still running Java 8 in production has few current options that are not end-of-life themselves.

## How the container and module layout differ from Spring

The README does not document Solon's internal request pipeline, so the mechanism has to be read from the repository layout rather than from a specification. The top level is a Maven multi-module build: solon-parent holds the parent POM, solon-projects holds the modules, solon-shortcuts holds convenience artifacts, and solon itself is the core. The build is driven by pom.xml at the root, with repository.xml and settings.xml alongside it for repository configuration. That structure tells you Solon is distributed as a set of Maven artifacts under the org.noear group, which is the coordinate the README links to on Maven Central.

The architecture claim in the README is non-java-ee architecture. In practice that means Solon does not implement the Servlet specification. There is no servlet container underneath, no web.xml, no ServletContext. A Solon application starts its own container in a main method, and the framework owns routing, parameter binding, and lifecycle. The companion schema images (solon_schema.png and solon_cloud_schema.png) are the project's own diagrams of how the core and the cloud layer relate; the README references them but does not reproduce them as text.

The ecosystem is deliberately split across repositories rather than bundled. solon-cloud covers distributed concerns, solon-ai covers AI integration, solon-flow covers workflow, and solon-expression covers expression evaluation. There are also IDE plugins for IntelliJ and VS Code, and build plugins for Maven and Gradle. This is a modular design, and it is also a fragmentation cost: a Spring user gets most of these concerns from a single BOM, while a Solon user assembles them from separate repositories with separate release cadences.

## Getting Solon from Maven Central

The README does not include a step-by-step install section, and it does not print a dependency snippet or a startup code sample. What it does give is the distribution channel: Maven Central, under the org.noear group, linked through Sonatype Central. The repository layout supplies the rest of the picture. The top level contains pom.xml, repository.xml, settings.xml, and a solon-parent module, which is the parent POM that manages versions for a project that depends on Solon.

The README also points to the official site at solon.noear.org and to the sample repository at gitee.com/opensolon/solon-examples, describing the latter as the official website supporting sample code repository. Those two links are where the actual install steps and code samples live. Anyone adopting Solon should start there rather than from the README, because the README is a feature summary and a repository index, not a getting-started guide.

The version to align with is the v4.0.6 release, published on 2026-08-17. The README does not list the individual artifact name for the core module, so confirm the exact coordinates against solon-examples before pinning anything in a production build. The same applies to the class and annotation names a Solon program uses to start: the README does not print them, so treat any example you find elsewhere as unverified until you have checked it against the sample repository.

What the repository layout does tell you is that a Solon application is started from a main method rather than from an external servlet container, because the framework is described as non-java-ee architecture. The README claims startup is 10 times faster and packaging 90% smaller than the comparison baseline, but it does not state what that baseline is, so treat those numbers as the project's own comparison rather than a measured result you can reproduce from the repository alone.

## The concurrency and footprint claims need a baseline

The README leads with 700% higher concurrency, 50% memory savings, 10 times faster startup, and 90% smaller packaging. It attributes the concurrency figure to a TechEmpower plaintext benchmark round. That is a real, publicly run benchmark family, and citing it is better than citing nothing. The problem is what the README omits: which framework Solon is being compared against, on what hardware, and in which configuration. A percentage without a baseline cannot be checked by a reader.

The packaging claim is the one most likely to hold up in practice, because it follows from the architecture. A non-Java-EE framework that does not pull in a servlet container, and that is assembled from individual modules rather than a broad starter, will produce a smaller artifact. Whether it is 90% smaller depends entirely on what you were packing before. A Spring Boot service with a thin dependency set and a Solon service with the same set will not differ by an order of magnitude.

There is a related omission. The README says the project supports native runtime and GraalVM native image, but it does not document the reflection configuration or build steps that native compilation typically requires. If native image is the reason you are interested, the README alone will not get you there; the sample repository and the official site are the places to look.

## Where Solon is the wrong choice

The clearest failure mode is dependency gravity. If your application depends on Spring Boot starters, Spring Security, Spring Data, or Spring Cloud components, Solon does not run them. The project offers solon-cloud as a counterpart, but a counterpart is a separate implementation with its own API, and the README does not claim binary or source compatibility with anything in the Spring ecosystem. The word replaceable in the repository description refers to replacing Spring, not to interoperating with it.

The second constraint is documentation language. The README exists in English, Chinese, Russian, and Japanese, and the project is clearly Chinese-led: the sample repository is hosted on Gitee, and the official site is solon.noear.org. The English README is a summary. It contains the feature table, the repository index, and links, but not the API reference. For a framework that owns your application lifecycle, that gap matters during onboarding and during incidents.

The third constraint is the Java 8 through 26 range itself. Supporting that many runtimes across solon, solon-java17, and solon-java25 means the project maintains parallel baselines. A team on Java 21 should verify which of those repositories is the intended source for their version before adopting, because the README lists them without saying which one a given Java release maps to.

## Solon against Spring Boot, and against staying put

The honest alternative is Spring Boot, and the difference is not performance, it is the programming model and the surrounding supply chain. Spring Boot builds on the Servlet stack or on reactive Netty and gives you auto-configuration, a starter for nearly every integration, and a decade of Stack Overflow answers. Solon builds its own container, ships modules as separate repositories, and gives you a smaller surface with far fewer third-party integrations. If your team's bottleneck is integration breadth, Spring wins. If your bottleneck is startup time in a container-heavy deployment and you are willing to write the integrations yourself, Solon's architecture is the reason to look.

The second alternative is doing nothing. A working Spring Boot service that meets its latency and memory targets has no reason to migrate, and the README offers no migration tooling. There is no Spring-to-Solon compatibility layer listed in the repository index. Porting means rewriting controllers, configuration binding, and dependency wiring by hand. That is a new-project decision, not a refactor.

A fair middle position: Solon is most defensible for a new service where you control the dependency list, and least defensible as a replacement inside an existing Spring estate. The repository layout supports that reading, since the ecosystem is organized as parallel modules rather than as adapters.

## Maintenance, releases, and licence

The repository is not archived. The last push was on 2026-08-17, the same day as the v4.0.6 release, and v4.0.5 and v4.0.4 landed on 2026-08-12 and 2026-07-30. That is a release cadence measured in weeks on the 4.0 line, which is the strongest available signal about how the project is run. The UPDATE_LOG.md and its versioned predecessors (UPDATE_LOG_v1.md, UPDATE_LOG_v2.md, UPDATE_LOG_v3.md) exist at the top level, so upgrade notes are kept in the repository rather than only on the website.

Upgrade cost is the thing to budget for. The project has shipped three major lines (V2.0.md, V3.0.md, V4.0.md are all present at the top level), and major-line moves in a framework that owns your container are not drop-in. The parallel solon-java17 and solon-java25 repositories add a second axis: your Java baseline and your Solon version both have to line up. Pin the Solon version explicitly rather than inheriting a range.

On licensing, Solon is Apache-2.0, which permits commercial use, modification, and redistribution with the usual notice and patent terms. The repository also carries NOTICE.template and NOTICE-license-mappings.xml, which suggests the project tracks third-party licence obligations for its dependencies. If you redistribute Solon inside a product, read those files and your own legal review; this article is not legal advice.

## Conclusion

Adopt Solon if you are starting a new Java service, want a non-Java-EE container, and are willing to work from Chinese-first documentation and a smaller plugin ecosystem. Do not adopt it if your stack depends on Spring Boot starters, Spring Security, or Spring Cloud components that have no Solon counterpart, or if you need English documentation with the depth of the Spring reference. Before committing, check that the specific modules you need (solon-cloud, solon-ai, solon-flow) are present in the repository list and that the version you pin matches the Java baseline you target.

## FAQ

### What is Solon?

Solon is a Java enterprise application development framework released under Apache-2.0, described in its README as being for full scenario and built on a non-Java-EE architecture. It is positioned as a replaceable alternative to Spring and supports Java 8 through Java 26 plus GraalVM native image.

### How do I install Solon?

The README does not give install steps. It points to Maven Central under the org.noear group, to the official site at solon.noear.org, and to the sample repository at gitee.com/opensolon/solon-examples, which the README calls the official website supporting sample code repository.

### Which Java versions does Solon support?

The README states java8 through java26, with native runtime support. The repository also lists separate solon-java17 and solon-java25 code repositories for those baselines.

### Is Solon a drop-in replacement for Spring Boot?

No. The repository description calls it replaceable spring, and the README describes a non-java-ee architecture with its own container and separate ecosystem repositories such as solon-cloud. There is no compatibility layer listed, so porting means rewriting controllers, configuration binding, and wiring.

## Sources

- [Official documentation](https://solon.noear.org)
- [Official README](https://github.com/opensolon/solon#readme)
- [Project repository](https://github.com/opensolon/solon)
- [Release notes](https://github.com/opensolon/solon/releases)

---

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