Should I upgrade to Micronaut 4 now?
Assess whether to move Micronaut services to Micronaut 4 now that Java 17 is the minimum baseline and framework-level changes affect deployment defaults, build plugins, and annotation processing.
Blockers
- requires_version: framework/micronaut-4 → runtime/java-17
- requires_version: framework/micronaut-4 → package/gradle-8
- requires_version: framework/micronaut-4 → package/micronaut-gradle-plugin-4x
- breaking_change_in: framework/micronaut-4 → package/micronaut-maven-plugin
Who this is for
- microservices
- enterprise
Candidates
Upgrade services to Micronaut 4 on Java 17 now
As of 2026-04-02, the official Micronaut 4 guide states that Micronaut 4 requires Java 17 for both building and running applications. The current official getting-started guide shows Micronaut version 4.10.9, and the main Micronaut 4 guide documents the Java 17 baseline, runtime-initialization changes for native-image alignment, and the completed `javax` to `jakarta` migration. The official upgrade guide also calls out build-system changes: Gradle 8 for generated apps, Micronaut Gradle plugin 4.x, a Maven plugin coordinate change to `io.micronaut.maven:micronaut-maven-plugin`, and annotation processor version alignment through `micronaut.core.version`. No framework pricing was surfaced in the official docs reviewed, so treat this primarily as a migration-risk and platform-baseline decision rather than a license-cost decision.
When to choose
Use this when your org is already standardizing on Java 17 and can absorb one migration wave across build, CI, container images, and IDE setup. It is the better choice when you want to stop carrying pre-Java-17 assumptions and can remediate `jakarta`, YAML, cloud-deduction, and annotation-processing changes in the same release train.
Tradeoffs
You align runtime and framework baselines immediately and remove ambiguity about supported build settings, but you take several coordinated changes at once: Java 17, plugin/BOM updates, annotation processor wiring, and behavior changes at deployment time.
Cautions
Blockers called out in official docs include: add SnakeYAML explicitly if you use YAML config; expect cloud environment deduction to be disabled by default; replace any remaining `javax.annotation` usage with `jakarta.annotation`; remove deprecated `runtime("lambda")`; and update Micronaut annotation processor coordinates and versions. For Kotlin builds, Micronaut 4 recommends migrating from kapt to KSP.
Delay the Micronaut 4 cutover and first standardize Java 17 plus build hygiene
As of 2026-04-02, the official Micronaut 4 materials show that the hard baseline shift is not just a JDK bump: the framework also changes plugin coordinates, BOM usage, annotation processor versioning, YAML dependency behavior, and cloud-environment deduction defaults. The official Micronaut 3.9.1 docs still emphasize correct annotation-processing setup in IDEs and build tooling, which means teams with inconsistent local and CI compiler behavior are likely to expose those problems during a Micronaut 4 migration. This path keeps the current framework line temporarily while you normalize Java 17 toolchains, container images, IDE annotation processing, and dependency hygiene before changing framework internals. No official pricing signal was identified in the reviewed sources, so the deferral case is about operational risk reduction, not subscription savings.
When to choose
Use this when services are business-critical, release windows are tight, or your build fleet still has mixed IDE/compiler behavior. It is the better choice when the decisive factor is reducing migration blast radius by separating Java 17 readiness from Micronaut 4 framework behavior changes.
Tradeoffs
This lowers immediate migration risk and makes failures easier to localize, but it extends the period where teams must remember that the framework upgrade is still pending. You also delay access to the Micronaut 4 baseline and keep a second migration step on the roadmap.
Cautions
Do not treat this as a no-op. The official Micronaut 4 docs show eventual blockers you will still need to clear: `jakarta` package migration, explicit SnakeYAML dependency for YAML config, disabled-by-default cloud deduction, updated annotation processor coordinates, and Java 17 as a hard minimum.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Should I upgrade to Micronaut 4 now?"