Micronaut Core: compile-time dependency injection for JVM services

What Micronaut Core is, and the problem it targets

Micronaut Core is the base module of the Micronaut Framework, a JVM framework for building modular applications in Java, Kotlin and Groovy. The README describes it as a full stack framework that supplies dependency injection and inversion of control, aspect oriented programming, and auto-configuration with sensible defaults. On top of that base, the framework provides distributed configuration, service discovery, HTTP routing and client-side load balancing for microservices, and the repository also contains modules for message-driven applications and command line applications.

The problem it targets is stated plainly in the README: the framework aims to avoid the downsides of Spring, Spring Boot and Grails. The listed downsides are startup time, memory footprint, reflection, proxies and runtime bytecode generation. That list is a design brief rather than a feature list. If your service starts quickly and stays small, the framework's main selling point does not apply to you. If you run many small services, or you pay for idle memory, or you package into a native image, the same list becomes the reason to look at it.

The audience is therefore specific. Teams already on the JVM, already comfortable with annotation-driven frameworks, and unhappy with one of those five costs. The README also names the lineage: the framework was created by people who had worked on Grails and learned from Spring, Spring Boot and Grails. That history explains the shape of the API, which will look familiar to anyone coming from those projects.

How the compile-time wiring actually works

The mechanism is stated in one sentence in the README: the framework infrastructure is pre-computed at compilation time, which reduces the logic required at runtime. In practice this means the annotation processor, which lives in the core-processor module visible in the repository layout, reads your annotations during compilation and emits the classes that would otherwise be built by scanning the classpath at startup. The README's list of avoided costs follows from that: minimal use of reflection, minimal use of proxies, and no runtime bytecode generation.

The trade-off is where the work happens. A reflection-based container resolves the graph when the application starts, so a mistake shows up as a startup failure. A compile-time container resolves it while javac or the Kotlin compiler runs, so the same mistake shows up as a compilation error. That is usually better, because you learn about it in the build rather than in a deployment. It also means the build is slower and the build is now part of your application's correctness. When a bean is not found, you are reading an annotation processor message, not a stack trace from a running server.

The repository layout shows how the framework is split. There are inject modules for Java, Groovy and Kotlin, including test variants such as inject-java-test and inject-kotlin-test. There are separate http-server, http-client, discovery-core and function modules, plus http-netty and http-server-netty for the Netty-based transport. The core-bom module is the bill of materials that pins the versions of these pieces together. That structure matters when you debug: a missing dependency is often a missing module rather than a missing configuration key.

Building Micronaut Core from source and running the docs build

The README does not give an install command for consuming the framework in an application. What it documents is how to build the framework itself from source: check out the code and run the Gradle wrapper. The wrapper script is present at the top level as gradlew, alongside gradlew.bat for Windows, so the command works on both platforms without a separate Gradle installation.

The publish step installs the built artifacts into your local Maven repository, which is what you would do if you wanted to test a change against a project of your own.

./gradlew publishToMavenLocal

After that command completes, the framework artifacts are available locally. The README does not list the coordinates or the version that gets published, so read them from the build output rather than assuming a value.

The second documented command builds the documentation. The README states the output location explicitly, which is useful because the generated HTML is the only offline copy of the reference material.

./gradlew docs

The result is written to build/docs/index.html according to the README. For application development the README points elsewhere: it directs readers to the documentation at micronaut.io and to guides.micronaut.io for example applications. Those are the two places to look for a project skeleton, not this repository.

Where the compile-time approach costs you

The clearest limitation is the one the README implies rather than states: because wiring is computed at compilation time, anything that depends on runtime classpath discovery sits awkwardly. The README says the framework uses minimal reflection and minimal proxies, not none. The inject modules include an inject-java-helper and an inject-java-helper2, which suggests that some injection scenarios need extra compiled support rather than being handled by the main processor alone. If your architecture depends on loading plugins from a directory at startup and having them registered automatically, that pattern needs deliberate handling here.

The second cost is build complexity. Adding an annotation processor changes your build in ways that are easy to underestimate: incremental compilation behaviour, IDE configuration, and the order in which generated sources become visible. A team that has never debugged a processor will spend its first afternoon on it. That is a one-time cost, but it is a real one, and it lands on every developer rather than on one infrastructure engineer.

The third is ecosystem shape. Micronaut Data and Micronaut-platform appear only in the search terms people use, not in the README text, so treat those as separate projects rather than as parts of micronaut-core. Any library you use needs either a Micronaut integration or a hand-written bean definition. In a Spring codebase, many of those integrations already exist; here you may be writing them.

Micronaut Core against Spring Boot, and against plain DI

The README names Spring, Spring Boot and Grails directly as the frameworks whose downsides Micronaut aims to avoid, so the comparison is the project's own framing rather than an outside judgement. The concrete difference is when the container builds its object graph. Spring Boot resolves and wires at runtime, with classpath scanning and, in recent versions, ahead-of-time processing as an option. Micronaut Core makes that the default: the annotation processor emits the wiring during compilation, and the README lists no runtime bytecode generation and minimal reflection as the result.

That difference shows up in three places. Startup, because there is less to do when the process begins. Memory, because fewer generated proxies and reflective metadata are retained. Native images, because GraalVM tooling has less dynamic behaviour to reason about; the repository carries a graal module and a GRAAL.md file at the top level, which indicates native image support is maintained in-tree rather than bolted on.

The alternative for a team that does not want a framework at all is plain dependency injection, for example a small manual wiring layer or a lighter container. The difference in approach is that you give up the auto-configuration and the HTTP routing that Micronaut Core provides and keep only the injection. That is a reasonable choice for a library or a small tool, and a poor one for a service that needs routing, configuration and discovery, because you will rebuild those pieces yourself. The honest summary is that Micronaut Core trades ecosystem breadth for build-time resolution, and the trade is only worth making if you actually feel one of the five costs the README lists.

Versioning, maintenance and the licence you are accepting

Micronaut Framework uses Semantic Versioning 2.0.0, per the README, which means the major version signals breaking changes. The README carves out an exception that matters when you upgrade: classes annotated with @Experimental or @Internal, which live in the io.micronaut.core.annotation package, are excluded from the public API. Code that touches those classes can break in a minor release without that being a semantic versioning violation. If you have written anything that reaches into framework internals, that is the first thing to check before an upgrade.

The repository is not archived and the last push was on 2026-09-22, with releases v5.2.1, v5.2.2 and v5.2.3 published on 2026-09-11, 2026-09-14 and 2026-09-21 respectively. That cadence, roughly weekly patch releases, is the upgrade cost you should plan for: patch releases are frequent, and the default branch is 5.3.x, so the next minor line is already in progress. The README notes that the core team develops and maintains the project through the Micronaut Foundation, which is the governance answer to the usual question about who is behind a framework.

The licence is Apache-2.0, stated in the repository metadata and present as a LICENSE file at the top level. Apache-2.0 is a permissive licence with an explicit patent grant, and it does not require you to publish your own source. That is a statement about the licence text, not legal advice; if you redistribute the framework or modify it, read the LICENSE file and your own organisation's policy.

Editorial conclusion

Adopt Micronaut Core when startup time, memory footprint and GraalVM native images matter more than the size of the ecosystem, and when your team is comfortable debugging annotation processors. Do not adopt it as a drop-in replacement for an existing Spring or Spring Boot codebase: the annotations, the configuration model and the build-time processing are different, and the README positions it as an alternative rather than a migration path. Before committing, check the micronaut-core BOM version you will pin, confirm that every third-party library you depend on has a Micronaut integration or a plain bean definition, and run your own startup measurement on the target runtime, because the repository's own claims about startup and memory are not benchmarked in the README.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. micronaut-projects/micronaut-core on GitHub
3. Project website
4. README
5. Releases