mica: a Spring Cloud component set that follows Boot upstream
A core toolkit for Spring Cloud microservice development: utility classes, captcha, HTTP, Redis, ip2region, XSS protection and more, ready to use out of the box.
At a glance
- What is it?
- A Java toolkit published as a long list of small Maven modules, versioned in lockstep with Spring Boot so that upgrading the framework does not mean auditing twenty dependencies.
- Who is it for?
- mica is best understood as a versioning strategy packaged as a library set. Each module is small enough to take or leave, and the release line moves with Spring Boot and Spring Cloud rather than against them, so staying current means adopting new framework versions instead of holding an old one.
- Can I use it commercially?
- Yes, with conditions. LGPL-3.0 is a weak copyleft licence: you can use it inside commercial and closed-source software, but if you distribute changes to its own files, you must publish those changes under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 29 days ago.
- What is it written in?
- Mainly Java, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 28, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A name that collides with a mineral
The repository is lets-mica/mica, and the word mica means the mineral. That is a real problem for discovery, and it shows up immediately if you search the name in English: the results are dominated by craft powders, pigment suppliers and resin hobbyists, not by a Java framework. The GitHub topics are more informative than the name, listing java, spring, spring-boot, spring-cloud, redis, okhttp3, swagger and mica.
The substance is a Spring Boot and Spring Cloud component toolkit described as a development base library and utility package, with support for both `web` and `webflux` stacks. The self-description in the repository metadata is similarly direct, naming the categories it covers: general utilities, captcha handling, HTTP clients, Redis access, IP geolocation and XSS filtering.
GitHub reports 2,236 stars and 374 forks. The open issue count is 4, which for a project this size is worth noticing rather than celebrating. A very low open issue count in a Java component library usually means issues are handled elsewhere, most likely on Gitee, where the README also lists a mirror under the author's account.
The default branch is `master` and the last recorded push was 2026-09-13. The project is hosted on a Chinese forge as well as GitHub, and the documentation lives on a site operated by the author, with a mirror on Yuque.
Version lines that follow the framework
The most useful thing in the README is the version table, which maps each mica release line to the Spring Boot and Spring Cloud versions it targets and to its maintenance state. Only three lines carry a maintained marker: 4.0.2 against Spring Boot 4.0.x and Spring Cloud 2025.1.x, 3.5.7 against 3.5.x and 2025, and 3.4.7 against 3.4.x and 2024.
Everything below those is marked as no longer maintained, and the list reaches back a long way: 3.3.6 and 3.2.12 against Spring Cloud 2023, 3.1.12 and 3.0.8 against 2022, 2.7.18.9 and 2.6.8 against 2021, 2.5.8 and 2.4.11 against 2020, and 2.1.1-GA against the Hoxton release train of Spring Cloud.
The numbering convention is stated as well: release versions follow the x.x.x form and deliberately track the Spring Boot version, while snapshot versions use the same form with a `-SNAPSHOT` suffix. Snapshots are pushed and published automatically, so a fix is available in a snapshot before the next tagged release.
That means the practical choice is which maintained line you adopt, and it is really a choice about which Spring Boot version you are on. There is no mica-specific upgrade path to reason about, because the framework moves first and the library follows.
Twenty modules, most of them optional
The directory listing is the clearest description of what mica actually contains, because each capability is its own Maven artifact with its own version. The set includes `mica-core` for general utilities, `mica-lite` as the assembled starter, `mica-redis` for Redis access, `mica-http` for HTTP clients, `mica-xss` for XSS filtering, `mica-captcha` for captcha handling, and `mica-ip2region` for IP geolocation.
Also present are `mica-bom` for dependency management, `mica-activerecord` for an active record pattern, `mica-caffeine` as a caching library integration, `mica-metrics` and `mica-prometheus` for metrics, `mica-openapi` for API documentation, `mica-logging` for logging, `mica-qrcode` for QR codes, `mica-spider`, `mica-holidays`, and `mica-ddddocr`, the newest addition.
This granularity is the design decision that matters. A project can adopt `mica-redis` alone and ignore everything else, with no obligation to take a framework opinion it does not want. The cost is a longer dependency tree to audit, which is the trade the library set makes explicit by publishing a bill of materials.
Two modules indicate the scope is wider than HTTP microservices. `mica-holidays` gained GraalVM ahead-of-time compilation support in version 3.2.2, and the same release fixed the IPv6 database file in `mica-ip2region` for that native image path. Native image support for a utility library is an unusual amount of care, and it is the kind of detail that suggests the author builds real deployments.
What changed in the 4.0 line
Release 4.0.2, published 2026-02-08, is the newest tagged release and the one that lines up with the current maintained table row. Its changelog is mostly a set of small, deliberate improvements rather than a redesign.
Three security changes stand out. The AES helper in `mica-core` switched to a random initialisation vector and added `encryptSafe` and `decryptSafe` methods alongside the existing ones, which is a meaningful change because a fixed IV with CBC mode was a known weakness. `DesUtil` was marked deprecated with an explicit recommendation to use `AesUtil` instead, and the RSA helper gained support for specifying the padding mode.
`mica-ip2region` was synced to a newer upstream version with both IPv4 and IPv6 support. `IpInfo` dropped the region field and gained an `isoCode` field, so that is a breaking change to any code reading the removed property. `mica-redis` gained a configurable thread pool size for Redis Streams and lost some unnecessary nullability annotations. And `mica-lite` fixed a startup log bug where the Swagger address printed the wrong port when several management ports were configured.
The release before that in the tag list, 3.2.4 from 2024-03-25, shows the project's development pattern: bug fixes from user reports on Gitee, each credited by name, alongside small library refinements such as range validation in `mica-core` validation and a fix for an empty field error in `mica-lite`.
A licence posture that differs from the ecosystem
mica is released under the GNU Lesser General Public License, and the README spends an unusually long section explaining what that means and what the author intends by it.
The explanation of LGPL itself is standard: it was designed mainly for libraries, and unlike GPL it lets commercial software reference the library through linking without being required to open source its own code. The stated consequence is that LGPL code works well as a third-party library referenced by commercial software, but is a poor fit for a commercial product that intends to modify the library and build a derivative.
Then the specifics begin. The project is free to use without modification for study, thesis work, company projects and paid freelance jobs. Modifying the code while staying closed source requires the author's permission. The README also asks that any reference cite mica and follow the licence. And it carries a Chinese software copyright registration number, 2020SR0411603.
Two clauses go beyond what a standard LGPL header says. The README states that unauthorised use, or re-publishing or commercialising in a way that does not follow LGPL, will be pursued. It also states that if the prohibition clause is found to have been violated, a licence fee of 19999 may be claimed.
For a library this is an unusual combination: a permissive-in-practice ecosystem licence on the surface, and an enforcement posture that reads more like a commercial contract underneath. Nothing prevents use, but a company that plans to fork a module and keep it closed should settle the question with the author first. The README links pigx and BladeX as the reference implementations the author considers best practice.
Documentation, ecosystems and one known bug
Documentation lives outside the repository rather than inside it. The README points to a documentation site for the 2.x line, an older wiki address, and a Yuque space that can be followed as a subscription. The repository itself carries `docs/`, a `CHANGELOG.md` for update records, and an English README alongside the Chinese one, so the primary page is Chinese and the translated version is the secondary one. Both README variants offer a language switch at the top.
There is a broader ecosystem of related projects under the author's accounts, including a Spring Boot starter helper, a WeChat starter for the JFinal ecosystem, an MQTT component built on t-io, an HTTP/2 cleartext approach for Spring Cloud microservices, and a permissions system. A separate benchmark repository exists for performance testing, which is the sort of thing most libraries omit.
The README also documents a known bug rather than hiding it. For bean property names in the pattern of a lowercase letter followed by an uppercase letter, map to bean and bean to map conversions are incorrect, and the cause is traced to an issue in Lombok. The author's position is that a fix will wait for a newer Lombok release and no compatibility shim will be added.
One more detail in the repository is worth noticing: alongside the usual files there are `AGENTS.md` and `CLAUDE.md` at the root, plus a `SECURITY.md` and a `.codacy.yml` for automated code review. A Java library publishing instructions for coding agents in its repository is increasingly common and still tells you something about how the project is maintained.
Editorial conclusion
mica is best understood as a versioning strategy packaged as a library set. Each module is small enough to take or leave, and the release line moves with Spring Boot and Spring Cloud rather than against them, so staying current means adopting new framework versions instead of holding an old one. The parts most likely to matter are the maintained lines listed in the README table, where only the newest three carry a maintained marker, and the security utility changes in version 4.0.2 that deprecate one cipher helper in favour of another. What deserves a careful read is the licence section: LGPL-3.0 with a software copyright registration number, a stated intention to pursue unauthorised commercial use, and a named authorisation fee. That is a different posture from most Spring ecosystem libraries, and it should be understood before the artifact is added to a commercial project, not after.
Frequently asked questions
What is mica and what is it used for?
It is a Java toolkit of Spring Boot and Spring Cloud helper modules, published under the net.dreamlu group. It covers utilities, captcha handling, HTTP clients, Redis access, IP geolocation with the ip2region data and XSS filtering, and supports both the web and webflux stacks. Each capability ships as its own Maven artifact so you can take the ones you need.
Which version of mica should I use?
Pick the line that matches your Spring Boot version. The README table marks 4.0.2, 3.5.7 and 3.4.7 as maintained against Spring Boot 4.0.x, 3.5.x and 3.4.x respectively. All earlier lines, from 3.3.6 back to 2.1.1-GA, are marked unmaintained. Release numbers deliberately track the Spring Boot version, and snapshot builds are published automatically after each push.
Can I use mica in a commercial closed-source project?
Yes for unmodified use. mica is licensed under LGPL-3.0, which the README explains allows commercial software to reference the library through linking without open sourcing its own code, and it states that free use without changing the source is fine for study, thesis work, company projects and freelance jobs. Modifying the code while keeping it closed requires the author's permission, and the README carries a Chinese software copyright registration number and states that a fee may be claimed for violation of its terms.
Does mica have known bugs or limitations?
The README documents one explicitly. For bean property names where the first letter is lowercase and the second uppercase, map to bean and bean to map conversions are incorrect. The cause is tracked to a Lombok issue, and the author states that no compatibility workaround will be added because it will be fixed in a newer Lombok release.
What changed in mica 4.0.2?
The February 2026 release added the mica-ddddocr captcha recognition module, switched the mica-core AES helper to a random initialisation vector with new encryptSafe and decryptSafe methods, deprecated DesUtil in favour of AesUtil, and let the RSA helper take a specified padding mode. It also synced mica-ip2region for IPv4 and IPv6, where IpInfo lost its region field and gained an isoCode field, and added a configurable thread pool size for Redis Streams.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/lets-mica-mica)