Blog / 04

Spring Tools 5.4 Adds Modulith Quick Fixes and MCP

WebRestart

Spring Tools 5.4.0 shipped on September 9, 2026. The headline is a set of validations that flag idiomatic Spring refactors and then apply them for you — @ApplicationModuleListener, @RestController, @SpringJUnitConfig and scope annotations — plus an MCP change that lets the Claude Code plugin read a project's logical structure instead of guessing at it from file names.

It ships for Visual Studio Code, Cursor, Eclipse, Theia and Claude Code. The Eclipse distribution is rebased on Eclipse 2026-09. The next release, 5.5.0, is scheduled for mid-December 2026.

The Spring Modulith validation is the interesting one

Spring Modulith's @ApplicationModuleListener is shorthand for a three-annotation stack that is easy to get subtly wrong:

@Async
@Transactional(propagation = Propagation.REQUIRES_NEW)
@TransactionalEventListener
public void on(OrderCompleted event) { ... }

The point of that combination is decoupling. The original business transaction commits first, then the integration runs asynchronously in a transaction of its own, so a failure downstream cannot roll back the unit of work that published the event. Miss the REQUIRES_NEW, or drop @Async, and you get something that still compiles and still looks event-driven but has quietly re-coupled two modules.

Spring Tools 5.4.0 now detects that hand-rolled stack and offers to collapse it (#1800). There are two quick fixes: convert a single method, or "Combine all into @ApplicationModuleListener in file" to do every affected method at once. Compatible attributes are preserved and unused imports are cleaned up.

Note the severity: this one reports at INFO by default, unlike the existing invalid-module-reference check, which is an ERROR. That is the right call — the three-annotation form is not wrong, just verbose — but it also means the findings will not show up in a problems panel filtered to warnings and above. In VS Code the knob is spring-boot.ls.problem.boot3.MODULITH_APPLICATION_MODULE_LISTENER; in Eclipse it is under Preferences → Spring → Validation, Boot 3.x category. Modulith project tracking is on by default.

Three more conversions land alongside it: @SpringJUnitConfig (#1403), @RestController (#1402) and specific @Scope annotations (#1401) — the @Controller + @ResponseBody and @Scope("prototype") patterns that survive in older codebases because nobody had a reason to touch them.

What the MCP change actually gives an agent

#1973 lets the Claude Code plugin render a project's logical structure over MCP. For a Spring Modulith project, that structure is the module graph: application modules as top-level nodes, components grouped by stereotype, and each type marked (API) or (internal) depending on whether it is exposed through a named interface.

That distinction is the part worth caring about. "Which types in this module are public API and which are internal" is not something an agent can infer reliably from package layout or visibility modifiers — Modulith's named interfaces are the authority, and until now the plugin had no way to hand that over. An agent asked to add a caller across a module boundary can now see that the type it wants is internal before it writes the reference, rather than after the validator rejects it.

The Claude Code plugin is not the VS Code extension in disguise. It runs a standalone language server variant that resolves the classpath through Maven or Gradle tooling and indexes types with Jandex, and it needs Java 21+. Installation is two commands:

claude plugin marketplace add https://cdn.spring.io/spring-tools/release/claude-plugins/marketplace.json
claude plugin install spring-tools@spring-tools-marketplace

Per-project validation settings go in .claude/spring-tools.properties or .claude/spring-tools.json and take effect on restart. Beyond structure, the plugin exposes Spring-specific diagnostics (missing annotations, incorrect bean wiring, version validation) and lookups for beans, components and request mappings.

Stability fixes worth knowing about

Several of the fixes in this release are the kind you only notice when they stop happening:

  • NPE while indexing broken source code (#1980) — the failure mode where one half-typed file takes the whole index down
  • A deadlock on sts.maven.goal during large builds (#1950)
  • Line-comment removal corrupting indentation during AST rewrites (#1962) — which matters precisely because this release adds four new rewrite-based quick fixes
  • A substantial speedup in repository-based version validation (#1963)

There is also a conversion from SQL string literals to text blocks (#1923) and improved HQL/JPQL parsing.

Should you upgrade?

If you run Spring Modulith, yes — the listener validation is the first tooling that checks the annotation stack you are supposed to be using. If you do not, this is a solid maintenance release: take it for the indexing and build-deadlock fixes and ignore the rest.

Primary sources: the release announcement and the 5.4.0.RELEASE notes.

Running Spring Boot underneath Jmix, or planning the Jmix 3.0 move to Spring Boot 4 and Java 21? Get in touch — we do Spring upgrades and modularisation work on long-lived codebases.

All posts