DEV Community: Istvan Verhas

Simplify Java and Spring Boot Migration with OpenRewrite (2026 Refresh)

Istvan Verhas — Fri, 25 Sep 2026 11:40:04 +0000

How This Post Was Created

There's a delightful irony at the heart of this article.

Back in March 2025, Ky Huynh wrote an excellent post, Simplify Java and SpringBoot migration with OpenRewrite, showing how to jump a legacy app from Java 8 / Spring Boot 2.x to Java 21 / Spring Boot 3.3. Huge kudos to Ky Huynh — the original article is genuinely great, and everything below stands on the shoulders of that work: the sample codebase, the structure, and the clear step-by-step walkthrough are all his. But it's now over a year and a half old, and in the fast-moving Java world that's practically a geological era. The target it recommended — Java 21 and Spring Boot 3.3 — is itself already legacy:

Java 25 is the current LTS (released September 2025). Java 21 stops receiving free public updates in September 2026.
Spring Boot 4.1 is out (June 2026), and the entire Spring Boot 3.x line left OSS support in June 2026.

In other words, the post that taught us how to escape end-of-life software has itself aged into end-of-life advice. OpenRewrite can rewrite your code, but there's no recipe to rewrite a blog post — so I asked an AI coding agent (Kiro CLI) to do it. It fetched the original article, checked the current versions of Java, Spring Boot, and every OpenRewrite module, discovered a brand-new distribution wrinkle (more on that below), and then — crucially — actually re-ran the whole migration on Ky's original sample project: cloning it, confirming the Spring Boot 2.7 / Java 8 baseline still builds, applying the new recipes to reach Java 25 / Spring Boot 4 / JUnit 6, and verifying the tests still pass. Every screenshot below is real output from that run, not a mock-up.

Consider this the "human-in-the-loop recipe" for keeping content current. Now, on to the actual migration.

Challenges of Migration

Older versions like Spring Boot 2.x and 3.x have reached end-of-life and no longer receive OSS support, so migrating to newer versions is essential for security, compatibility, and performance. The process still comes with the same familiar challenges:

1. Breaking Changes: Major upgrades introduce breaking changes. Spring Boot 3.x already required Java 17 and the move from javax.* to jakarta.*. Spring Boot 4.x raises the bar again, requiring Java 17+ (with Java 21/25 recommended) and building on Spring Framework 7.

2. Deprecated APIs: Commonly used APIs and patterns get deprecated and need replacements.

3. Manual Updates: Traditional migration means manually bumping dependencies, refactoring code, and fixing compatibility issues.

4. Time-Consuming: Large codebases can take weeks or months, increasing project cost and risk.

5. Testing Burden: Every change must be thoroughly tested to ensure functionality is intact.

So how do we simplify and accelerate this? This is where OpenRewrite comes in.

OpenRewrite

OpenRewrite is an open-source tool for automated, large-scale code refactoring that helps teams pay down technical debt. It provides prebuilt refactoring recipes for framework migrations, security fixes, and code styling, cutting effort from hours (or weeks) to minutes.

Plugins for Maven and Gradle make it easy to apply these changes across repositories. Originally focused on Java, the community keeps expanding support to more languages and frameworks.

Key Features

Automated Refactoring: Automatically updates code syntax, dependencies, and patterns
Recipe-based: Uses declarative recipes to define transformation rules
Style Preservation: Maintains original code formatting and comments
Large-Scale Changes: Processes entire codebases consistently
Extensible: Supports custom recipes for specific migration needs

How does it work?

OpenRewrite modifies Lossless Semantic Trees (LSTs), which represent your source code, then prints them back into source.
You review the changes and commit them as needed.
Modifications are made by Visitors, grouped into Recipes.
Recipes keep changes minimally invasive and preserve the original formatting.

⚠️ New in 2026: the Code Genome Project repository

One thing that has changed significantly since the original post: OpenRewrite recipe artifacts are moving from Maven Central to the Code Genome Project repository, which requires authentication.

The rewrite-maven-plugin itself still resolves normally, but if a recipe module doesn't resolve for you, add the Code Genome Project repository (with credentials) to your pom.xml or settings.xml. If you're pinning older recipe versions that are still on Maven Central, you may not hit this yet — but it's the single biggest "gotcha" for anyone following an older tutorial today.

Practice

In this post I'll demonstrate how to migrate a simple CRUD Spring Boot application built with Java 8, Spring Boot 2.x, and JUnit 4 to Java 25, Spring Boot 4, and JUnit 6 using OpenRewrite.

Codebase

1) pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.7.14</version>
        <relativePath/>
    </parent>

    <groupId>com.example</groupId>
    <artifactId>demo</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>demo</name>
    <description>Demo project for Spring Boot Migration</description>

    <properties>
        <java.version>1.8</java.version>
    </properties>

    <dependencies>
        <!-- dependencies: starter web, data-jpa, etc -->
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>
</project>

2) UserController.java

@RestController
@RequestMapping("/api/users")
public class UserController {

    @Autowired
    private UserRepository userRepository;

    @Autowired
    private UserService userService;

    @RequestMapping(method = RequestMethod.GET)
    public List<User> getAllUsers() {
        return userRepository.findAll();
    }

    @RequestMapping(method = RequestMethod.POST)
    public ResponseEntity<?> createUser(@Valid @RequestBody User user) {
        User savedUser = userRepository.save(user);
        return ResponseEntity.ok().build();
    }

    @RequestMapping(value = "/{id}", method = RequestMethod.GET)
    public ResponseEntity<User> getUserById(@PathVariable("id") Long id) {
        User user = userRepository.findById(id).orElse(null);
        return user != null ? ResponseEntity.ok(user) : ResponseEntity.notFound().build();
    }

    @RequestMapping(value = "/username")
    public ResponseEntity<User> getUserByUsername(@RequestParam String username) {
        User user = userService.findByUsername(username);
        return user != null ? ResponseEntity.ok(user) : ResponseEntity.notFound().build();
    }

}

3) UserService.java

@Service
public class UserService {

    @Autowired
    private UserRepository userRepository;

    public User findByUsername(String username) {
        return userRepository.findByUsernameNative(username);
    }
}

4) UserRepository.java

@Repository
public interface UserRepository extends JpaRepository<User, Long> {

    @Query(value = "SELECT * FROM users WHERE username = ?1", nativeQuery = true)
    User findByUsernameNative(String username);

}

5) User.java

import javax.persistence.*;
import javax.validation.constraints.NotNull;

@Entity
@Table(name = "users")
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;

    @NotNull
    @Column(nullable = false)
    private String username;

    @Column
    private String email;

    // setter, getter
}

6) UserControllerTest.java

@RunWith(SpringRunner.class)
@SpringBootTest
@AutoConfigureMockMvc
public class UserControllerTest {

    @Autowired
    private MockMvc mockMvc;

    @Autowired
    private UserRepository userRepository;

    @Before
    public void setup() {
        userRepository.deleteAll();
    }

    @Test
    public void testCreateUser() throws Exception {
        String userJson = "{\"username\":\"testuser\",\"email\":\"test@example.com\"}";

        mockMvc.perform(MockMvcRequestBuilders.post("/api/users")
                .contentType(MediaType.APPLICATION_JSON)
                .content(userJson))
                .andExpect(MockMvcResultMatchers.status().isOk());
    }

    @Test
    public void testGetUser() throws Exception {
        User user = new User();
        user.setUsername("testuser");
        user.setEmail("test@example.com");
        userRepository.save(user);

        mockMvc.perform(MockMvcRequestBuilders.get("/api/users/" + user.getId()))
                .andExpect(MockMvcResultMatchers.status().isOk())
                .andExpect(MockMvcResultMatchers.jsonPath("$.username").value("testuser"));
    }
}

Manual migration

Before reaching for OpenRewrite, let's see what happens if we manually jump straight to Java 25 and Spring Boot 4.

First, update pom.xml:

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>4.0.0</version>
    <relativePath/>
</parent>

<properties>
    <java.version>25</java.version>
</properties>

Next, clean and build the project with Maven:

mvn clean install

You'll be greeted by a wall of compilation errors — javax.* imports that no longer exist, deprecated APIs, JUnit 4 annotations that don't compile against JUnit 5, and Spring configuration properties that were renamed or removed across two major versions. Doing this by hand across a real codebase is exactly the slog OpenRewrite was built to eliminate.

Here's the actual output from doing exactly that on the sample project — bumping the parent to Spring Boot 4 and java.version to 25, then running mvn clean compile on JDK 25:

Twelve compilation errors before you've fixed a single line by hand. Okay, let's revert those changes and migrate with OpenRewrite instead.

Migration with OpenRewrite

Add the OpenRewrite plugin

In pom.xml, add the OpenRewrite Maven plugin (Gradle users can add the Gradle plugin). Note the version bump — the original post used 6.3.2; the plugin used for this walkthrough is 6.46.1 (the current line is 6.4x):

<build>
    <plugins>
        <plugin>
            <groupId>org.openrewrite.maven</groupId>
            <artifactId>rewrite-maven-plugin</artifactId>
            <version>6.46.1</version>
        </plugin>
    </plugins>
</build>

Choose the recipes for migration

To discover all the available recipes, check the Recipe catalog, which lists everything for Java, Spring Boot, Hibernate, Quarkus, and more.

For a full modernization, I'll chain four recipes: Java 8 → 25, JUnit 4 → 5, JUnit 5 → 6, and Spring Boot → 4.0. A nice detail here: the Spring Boot 4 recipe internally runs the intermediate upgrades (2.x → 3.x → 4.x) for you, so you don't have to stage them manually.

Add the recipes and their recipe modules to pom.xml. The versions below are the ones actually used for this walkthrough; recipe modules move quickly (roughly a release every 2–4 weeks), so always cross-check the latest versions of every OpenRewrite module:

<plugin>
    <groupId>org.openrewrite.maven</groupId>
    <artifactId>rewrite-maven-plugin</artifactId>
    <version>6.46.1</version>
    <configuration>
        <exportDatatables>true</exportDatatables>
        <activeRecipes>
            <recipe>org.openrewrite.java.migrate.UpgradeToJava25</recipe>
            <recipe>org.openrewrite.java.spring.boot2.SpringBoot2JUnit4to5Migration</recipe>
            <recipe>org.openrewrite.java.testing.junit6.JUnit5to6Migration</recipe>
            <recipe>org.openrewrite.java.spring.boot4.UpgradeSpringBoot_4_0</recipe>
        </activeRecipes>
    </configuration>
    <dependencies>
        <dependency>
            <groupId>org.openrewrite.recipe</groupId>
            <artifactId>rewrite-migrate-java</artifactId>
            <version>3.42.1</version>
        </dependency>
        <dependency>
            <groupId>org.openrewrite.recipe</groupId>
            <artifactId>rewrite-spring</artifactId>
            <version>6.37.1</version>
        </dependency>
        <dependency>
            <groupId>org.openrewrite.recipe</groupId>
            <artifactId>rewrite-testing-frameworks</artifactId>
            <version>3.44.0</version>
        </dependency>
    </dependencies>
</plugin>

Note on Java 25: the rewrite-migrate-java module ships incremental recipes — UpgradeToJava17, UpgradeToJava21, and now UpgradeToJava25. The UpgradeToJava25 recipe transparently chains the earlier steps (25 → 21 → 17 → 11), so you can target the current LTS directly, as this walkthrough does. The Spring Boot 4 upgrade also independently ensures your build targets a Java version compatible with Spring Boot 4.

Note on the Code Genome Project: at the time of writing, the recipe module versions above still resolved fine from Maven Central — but OpenRewrite is actively migrating recipe distribution to the Code Genome Project repository, which requires authentication. If a newer recipe module fails to resolve, add that repository (with credentials) to your pom.xml or settings.xml. This distribution change is the biggest thing to watch for since the 2025 version of this tutorial.

Already partway there? The same config still works

You might already have done part of this journey — say you migrated to Java 17, Spring Boot 3, and JUnit 5 a while ago and only now want to reach Java 25 / Spring Boot 4 / JUnit 6. The good news: you can use the exact same configuration above. OpenRewrite recipes are effectively idempotent — they operate on the Lossless Semantic Tree and only make a change where one is actually needed. Code that has already been upgraded simply won't be touched.

So the UpgradeToJava25 recipe leaves your already-Java-17+ code alone (it only applies the steps you still need), SpringBoot2JUnit4to5Migration does nothing if there's no JUnit 4 left, and the Spring Boot 4 recipe skips the 2.x → 3.x steps you've already completed and picks up only from where you are. There's no need to build a different, "resume-from-here" configuration for partially-migrated projects — point the same recipes at the codebase, run dryRun to confirm the scope, and only the genuinely outstanding changes show up in the diff.

Now install the plugin and its recipes:

mvn clean install

Preview the migration

OpenRewrite provides a dryRun mode so you can preview changes before applying them:

mvn rewrite:dryRun

This writes a patch file (by default under target/rewrite/rewrite.patch) that you can inspect with git diff or any diff viewer — no source files are touched. The console prints the full recipe tree it would apply, so you can see exactly how the high-level recipes decompose into the intermediate steps:

Notice how UpgradeSpringBoot_4_0 transparently runs the whole 3.5 → 3.4 → … → 3.0 chain, then Spring Framework 6.0, then the Jakarta EE 10 javax.* → jakarta.* migration. You didn't have to stage any of that. OpenRewrite even prints an "Estimate time saved: 2h 34m" — for a five-file toy project.

Apply the migration

When you're happy with the preview, run:

mvn rewrite:run

Then use your IDE or a diff checker to review the changes. Here's what actually happened on the sample project (Spring Boot 2.7.14 / Java 8 / JUnit 4 → Spring Boot 4.0.8 / Java 25 / JUnit 6):

1. Updated pom.xml — the Spring Boot parent jumps from 2.7.14 to 4.0.8, java.version from 1.8 to 25, spring-boot-starter-web becomes the new Boot 4 modular spring-boot-starter-webmvc, and the old JUnit 4 dependency is replaced with spring-boot-starter-webmvc-test:

2. Updated Controller — migrates javax.validation.Valid to jakarta.validation.Valid, and swaps every @RequestMapping(method = ...) for the dedicated @GetMapping / @PostMapping annotations:

3. Updated Entity and Repository — the JPA/validation imports on the User entity move from javax.* to jakarta.*, and — a nice bonus — the repository's @Query(..., nativeQuery = true) is rewritten to the newer dedicated @NativeQuery annotation:

4. Updated Unit Test — replaces JUnit 4's @RunWith(SpringRunner.class) and @Before with JUnit Jupiter's @BeforeEach (dropping the now-unnecessary SpringRunner entirely), and updates AutoConfigureMockMvc to its new Spring Boot 4 spring-boot-webmvc-test package:

Because the Spring Boot 4 recipe runs the intermediate 2.x → 3.x → 4.x steps, you also get the Spring Framework 6/7 property renames and configuration-key migrations handled along the way.

Verify it actually works

The real test of any migration isn't the diff — it's whether the result compiles and the tests still pass. On JDK 25, with the migrated Spring Boot 4.0.8 / JUnit 6 code:

Green across the board. The same two tests that passed on Spring Boot 2.7 / JUnit 4 now pass on Spring Boot 4 / JUnit 6, without a single line changed by hand.

Limitations

OpenRewrite successfully carries the app to Java 25 and Spring Boot 4, but the limitations from the original post still hold — and are worth restating:

Because OpenRewrite relies on predefined recipes, it supports many common frameworks but not all of them. If you depend on a third-party library that lacks a recipe (the classic example being something like Ehcache2 → Ehcache3), you'll need to either write a custom recipe or handle that part manually.

If you write a custom recipe, consider contributing it back to the OpenRewrite community to help others facing the same migration.

A newer, practical limitation: with recipes moving to the Code Genome Project, first-time setup now involves configuring an authenticated repository. Budget a little extra time for that in CI environments.

Summary

OpenRewrite still dramatically simplifies Java and Spring Boot migration by:

Automating repetitive code changes
Reducing migration time and effort
Minimizing human error
Standardizing the migration approach

What has changed in the year and a half since the original post is the destination: the sensible target is now Java 25, Spring Boot 4, and JUnit 6, applied with a much newer plugin (6.46.1) and recipe modules that are migrating from Maven Central to the Code Genome Project. The workflow — add plugin, pick recipes, dryRun, run, review — is reassuringly the same.

OpenRewrite still doesn't eliminate the need for testing and validation, but it removes most of the mechanical toil so you can focus on the genuinely tricky parts: business logic and the corners no recipe covers yet.

And if you take one meta-lesson from this refresh: content ages just like code. The difference is that code has OpenRewrite — content still needs a human (or a helpful agent) to keep it current.

Credits

All the real credit for the approach goes to Ky Huynh. This is a 2026 refresh of his original post, Simplify Java and SpringBoot migration with OpenRewrite — the walkthrough structure and the sample codebase (hgky95/TIL) are his, so please go read (and give some love to) the original.

Unlike the versions and recipe numbers, the screenshots in this post are all freshly captured — the migration was actually run on Ky's sample project (Spring Boot 2.7.14 / Java 8 / JUnit 4) against Java 25, Spring Boot 4.0.8, and JUnit 6, and every diff, the dryRun recipe tree, the manual-failure output, and the passing test run are the genuine console/git diff output from that run, rendered for readability. In other words: the versions were verified, the migration was executed end-to-end, the tests pass, and the images show exactly what happened — drafted with an AI coding agent and reviewed by a human.

References

Happy 8th Birthday, JEP 8209434 — Here's Your Preview Implementation

Istvan Verhas — Thu, 13 Aug 2026 16:03:09 +0000

Today, August 13, 2026, marks exactly 8 years since Brian Goetz filed JEP 8209434: Concise Method Bodies — a draft proposal to align method body syntax with lambda expression syntax in Java.

Eight years. Still in draft status. Still not in any Java release.

So I built it myself with Kiro.

What JEP 8209434 Proposes

Two new forms for method bodies that eliminate boilerplate in delegation and simple methods:

// Expression form: -> 
public int size() -> c.size();

// Method reference form: =
public int size() = aList::size;

These expand to exactly what you'd expect:

public int size() { return c.size(); }
public int size() { return aList.size(); }

If you've ever written a decorator, adapter, or any class that delegates to another object, you know the pain. The JDK's own Collections.UnmodifiableCollection has 14 methods that are nothing but { return c.something(); }. With concise method bodies, they become one-liners.

Why Wait?

The JEP has been in "Draft" status since 2018. No target release. No preview flag. Meanwhile, C# shipped expression-bodied members in 2015. Kotlin has had single-expression functions since day one.

Java developers deserve this too. And there's nothing preventing us from having it today — as a source code preprocessor.

The Preprocessor

java-composition is a source-to-source transformer. You write concise method bodies in your .java files, and the preprocessor expands them into standard Java before javac ever sees them.

Your IDE sees the concise source. The compiler sees standard Java. Any Java version from 8 onwards.

The Expression Form (`->`)

Purely syntactic — no type resolution needed:

// Non-void: wraps in return
String getName() -> this.name;
int add(int a, int b) -> a + b;
int abs(int x) -> x >= 0 ? x : -x;

// Void: expression statement
void close() -> stream.close();
void log(String msg) -> System.out.println(msg);

The Method Reference Form (`=`)

The method reference is invoked with the method's parameters. The preprocessor infers which method is being referenced and generates the correct invocation:

// Bound instance — receiver is the expression before ::
public int size() = aList::size;
// → return aList.size();

// Unbound instance — first parameter becomes receiver  
boolean isEmpty(String s) = String::isEmpty;
// → return s.isEmpty();

// Static — all parameters become arguments
int max(int a, int b) = Math::max;
// → return Math.max(a, b);

// Constructor
static Foo make(int a, int b) = Foo::new;
// → return new Foo(a, b);

Real-World Example: JDK's UnmodifiableCollection

Before:

static class UnmodifiableCollection<E> implements Collection<E> {
    final Collection<? extends E> c;

    public int size()                 {return c.size();}
    public boolean isEmpty()          {return c.isEmpty();}
    public boolean contains(Object o) {return c.contains(o);}
    public Object[] toArray()         {return c.toArray();}
    public <T> T[] toArray(T[] a)     {return c.toArray(a);}
    public String toString()          {return c.toString();}
    // ... 8 more like this
}

After:

static class UnmodifiableCollection<E> implements Collection<E> {
    final Collection<? extends E> c;

    public int size()                 -> c.size();
    public boolean isEmpty()          -> c.isEmpty();
    public boolean contains(Object o) -> c.contains(o);
    public Object[] toArray()         -> c.toArray();
    public <T> T[] toArray(T[] a)     -> c.toArray(a);
    public String toString()          -> c.toString();
    // ... 8 more like this
}

Same semantics. Half the noise.

How It Works

Under the hood, the tool:

Forks JavaParser (the standard Java parser library) and extends its grammar to recognize -> Expression ; and = MethodReference ; as valid method bodies
Stores concise bodies in the AST without expanding them — this enables future transformations to build on top
Runs transformation passes that expand concise forms into standard BlockStmt bodies
Pretty-prints the result as standard Java

For the = form, the preprocessor infers the referenced method from the source tree and classpath to generate the correct invocation. This is the only part that requires configuration (a classpath parameter).

API

// Expression form only (no classpath needed)
var preprocessor = new Preprocessor(sourceRoot, targetRoot);
preprocessor.process(Path.of("com/example/MyClass.java"));

// Method reference form (classpath needed for type resolution)
var preprocessor = new Preprocessor(sourceRoot, targetRoot, List.of(
    Path.of("lib/dependency.jar")
));
preprocessor.process(Path.of("com/example/MyClass.java"));

Works on Any Java Version

The output is plain Java. No lambdas, no var, no records — just method bodies with return statements. If your project targets Java 8, the output compiles with Java 8. If you target 21, same.

The preprocessor itself runs on Java 8 and above — it has no runtime dependency on modern Java features.

What's Next

This is just the beginning. The project roadmap includes:

Maven plugin — drop-in build integration (generate-sources phase)
Gradle plugin — same for Gradle
Shaded JAR — single dependency with no classpath conflicts
Published to Maven Central — guru.mocker:java-composition

And beyond that, the real dream: wildcard delegation.

class MyList<T> implements List<T> {
    private final List<T> delegate;

    List::* = delegate::*;  // All List methods delegate to 'delegate'

    // Override only what you need
    public boolean add(T e) {
        log("adding: " + e);
        return delegate.add(e);
    }
}

One line to generate dozens of forwarding methods. Composition as a first-class pattern.

Try It

The code is at github.com/verhasi/java-composition. Clone, build, and start writing concise method bodies today.

git clone git@github.com:verhasi/java-composition.git
cd java-composition
cd javaparser && ./mvnw clean install -DskipTests && cd ..
mvn clean test -pl preprocessor

All 31 tests pass. Real-world tested against the JDK's own Collections.java.

Happy 8th birthday, JEP 8209434. We got tired of waiting.

OpenAPI Spec Validation in Maven Is Now a First-Class Citizen (v7.24.0)

Istvan Verhas — Mon, 20 Jul 2026 12:18:37 +0000

OpenAPI Generator v7.24.0 shipped with 170+ enhancements, but one addition quietly fills a gap that's been annoying Java teams for years: a dedicated validate goal for the Maven plugin.

Until now, validating an OpenAPI specification in a Maven workflow meant either running the full generate goal (slow, unnecessary I/O) or pulling in external plugins. If your team maintains an "API Contract" module — where specs live without immediate code generation — you had no lightweight way to verify those contracts as part of the build.

That changes now.

The Problem

Consider a typical API-first project structure:

my-service/
├── api-contract/          ← OpenAPI specs live here (no code generation)
│   └── src/main/resources/
│       └── openapi.yaml
├── service-impl/          ← Generated code + business logic
└── service-client/        ← Generated client SDK

The api-contract module exists purely to version and validate specs. But without a validate goal, your CI pipeline couldn't catch spec errors until the downstream generate step — minutes later, buried in code generation failures.

The Solution: `validate` Goal

<plugin>
    <groupId>org.openapitools</groupId>
    <artifactId>openapi-generator-maven-plugin</artifactId>
    <version>7.24.0</version>
    <executions>
        <execution>
            <phase>validate</phase>
            <goals>
                <goal>validate</goal>
            </goals>
            <configuration>
                <inputSpec>${project.basedir}/src/main/resources/api/openapi.yaml</inputSpec>
            </configuration>
        </execution>
    </executions>
</plugin>

That's it. Your spec is validated at the very beginning of the Maven lifecycle — before compile, before generate, before anything else.

Why This Matters

1. Fail-Fast CI/CD

Broken specs halt the pipeline in seconds rather than waiting minutes for downstream code generation and compilation failures. The validation runs the same rule-based engine (OpenApiEvaluator) that powers the CLI validate command — deep structural and semantic checks, not just YAML syntax.

2. No Unnecessary Work

The validate goal performs zero I/O beyond reading the spec. No file generation, no template processing, no output directories. Pure validation.

3. Bulk Validation

Got a multi-API repository? Use inputSpecRootDirectory to validate all specs in one pass:

<configuration>
    <inputSpecRootDirectory>${project.basedir}/src/main/resources/apis/</inputSpecRootDirectory>
</configuration>

No more separate execution blocks per file. All validation issues across your entire spec ecosystem in a single Maven invocation.

4. Eclipse/m2e Integration

The goal includes proper lifecycle-mapping-metadata.xml configuration, so Eclipse users get incremental validation on workspace file changes. Edit your spec, save, see errors immediately.

Behavior

Errors (structural/semantic violations): Fail the build with actionable messages
Recommendations (best practice suggestions): Logged but non-blocking
Skip support: Honors the same skip flags as the generate goal

The Bigger Picture: Contract-First Development

This feature enables a cleaner separation in contract-first (API-first) development:

mvn validate    ← Spec is correct (new goal!)
mvn generate    ← Code is generated from spec
mvn compile     ← Generated + hand-written code compiles
mvn test        ← Everything works together

Each phase does one thing. The validate goal ensures you never waste time generating code from a broken spec.

Try It

Upgrade to openapi-generator-maven-plugin 7.24.0 and add the execution block above. If you maintain API contract modules that don't generate code, this is the missing piece for your build pipeline.

Links

Full disclosure: I authored this contribution (PR #23911). The implementation leverages the existing OpenApiEvaluator rule engine from the CLI and wraps it as a Maven lifecycle component.

Onboarding Your AI Pair Programmer: From Spec-Driven Development to Kiro Powers

Istvan Verhas — Sat, 11 Jul 2026 17:12:43 +0000

The Problem Nobody Talks About

Every developer who's used an AI coding assistant has experienced this: you ask it to contribute to your project and it produces something that works but doesn't belong. The code compiles, the tests pass, but a seasoned contributor would never write it that way. The AI doesn't know your project's conventions, architectural decisions, or the unwritten rules that make a contribution feel native.

We solved this problem for human contributors decades ago. It's called onboarding.

The Insight: AI Needs Onboarding Too

When a new developer joins a project, they don't start writing code immediately. They:

Read the documentation — CONTRIBUTING.md, wiki pages, architecture guides
Study merged PRs — Understanding "the way things are done"
Study the source code — Internalizing patterns and conventions
Observe rejected PRs — Learning what NOT to do
Internalize patterns — Building a mental model of project culture
Apply knowledge — Contributing effectively with fewer review cycles

An AI assistant that skips this process is like a contractor who starts coding without reading the project docs. Technically capable, but culturally oblivious.

The difference: A human stores onboarding knowledge in memory. An AI needs it stored in structured documentation that persists between sessions.

Spec-Driven Development Meets AI Memory

If you practice spec-driven development — writing requirements, design documents, and quality criteria before implementation — you already have the mindset for this. AI onboarding is simply extending that discipline to cover how your AI team member should think about your project.

The deliverable isn't code. It's a steering documentation system — a structured knowledge base that transforms your AI from a generic code generator into a project-aware contributor.

The Story: A Real-World Wake-Up Call

We (Kiro and me) developed this approach while contributing to JavaParser, a 6,000+ star open source project with strict architectural standards. After receiving maintainer feedback on our first PR that highlighted 8 code quality issues (not bugs — the code worked, but it bypassed project abstractions), we realized: the AI needed to be onboarded properly.

The maintainer's feedback boiled down to:

Use the metamodel API, not raw reflection
Test behavioral contracts, not implementation details
One PR = One concern, no exceptions
Provide evidence for every claimed fix

None of these were documented bugs. They were cultural knowledge — the kind you only learn by being part of the project. Exactly what onboarding is for.

The Architecture: Modular Steering System

We designed a layered knowledge system that balances always-available guidance with context-specific depth:

Three layers:

Core Principles — Non-negotiable rules that apply to every contribution. Architecture patterns, code style requirements, process essentials. Always loaded.
Quick Reference — Actionable guidance for common scenarios. Step-by-step workflows, checklists, decision trees, anti-patterns with corrections. Always loaded.
On-Demand Modules — Deep knowledge for specific contexts. Only loaded when relevant, keeping the AI's context window efficient for actual work.

Memory Efficiency

With a 1M token context window, the always-loaded core takes ~0.35% of available context. Even with an on-demand module loaded, total steering overhead stays under 3%. The AI has 97%+ of its capacity available for actual work.

Compare this to a human: you can't "unload" your project knowledge when working. The AI's modular memory is actually more efficient than ours.

The Process: Phased Onboarding

Phase 0: Documentation Study (~1 session)

Read all existing project documentation and extract patterns:

Contributing guidelines, README, wiki pages
CI/CD configurations (reveals automated quality gates)
Build scripts (reveals process dependencies)
Representative source files (reveals implementation patterns)

Deliverable: Working steering system — immediately usable.

Phase 1: Recent PR Analysis (~2-3 sessions)

Study 50-100 recent merged PRs to learn implicit patterns:

Maintainer feedback themes (what gets called out repeatedly)
Success patterns (what gets approved smoothly)
Communication norms (how discussions are conducted)

Deliverable: Priority modules for highest-impact areas.

Phase 2: Deep Historical Analysis (~3-4 sessions)

Comprehensive pattern extraction from project history:

Architectural decisions and their rationale
Pattern evolution over time
Anti-patterns from rejected approaches

Deliverable: Complete module library covering all major contribution scenarios.

Phase 3: Community Integration (~1-2 sessions)

Optimization and publication for broader adoption:

Module cross-linking and performance optimization
Integration with project's existing documentation
Validation through real-world contributions

Deliverable: Published, community-shareable resource.

Quality Assurance: How Do You Know It Works?

This is where spec-driven thinking pays off. We defined quality gates before starting:

Source Validation — Only official, maintainer-authored content informs the guide
Pattern Consistency — No contradictory guidance across modules
Coverage Baseline — Gaps explicitly identified and tracked
Usability Test — Simulate a real contribution scenario using only the guide

The usability test is the critical one. After creating our steering system, Kiro walked through our actual PR scenario (fixing a visitor generator) using only the guide. Every decision point was covered. Every common mistake was documented with corrections.
This kind of task to step out of the context is hard for a human, but any AI can handle it easily.

The Evolution: From Files to Kiro Powers

Here's where it gets interesting. While building this system, we faced a practical problem: where do these steering files live? They don't belong in the project repo (the maintainers didn't ask for them). They need to be available regardless of which branch you're on. And ideally, other contributors could reuse them.

Then we discovered Kiro Powers.

Powers are Kiro's native mechanism for packaging specialized knowledge — exactly what we'd built. A Power bundles steering files with optional MCP tools, hooks, and activation keywords. When you mention relevant topics in conversation, Kiro loads the appropriate knowledge automatically.

Our steering system mapped almost 1:1 to the Power format:

javaparser-contributor/
├── POWER.md                          # Core principles + steering routing
└── steering/
    ├── quick-reference.md           # Common scenarios
    ├── generator-development.md     # On-demand: generator work
    ├── pr-workflow.md               # On-demand: PR process
    └── metamodel-patterns.md        # On-demand: metamodel changes

This solved every problem at once:

No git conflicts — Power lives in its own repo
Available across all branches — Kiro loads it independently
Community shareable — One-click install from GitHub
Context-aware — Keywords trigger the right modules automatically

The methodology we developed independently turned out to align perfectly with Kiro's product architecture. We were building a Power without knowing it.
Maybe Kiro knew about this approach all along, but kept it well hidden.

Real Results (Phase 0)

Before onboarding:

Maintainer flagged 8 issues across code quality, test quality, and scope management
Multiple review cycles needed
Time spent learning project patterns through trial and error

After completing Phase 0:

Guide covers all 8 feedback patterns that were raised
Metamodel-first principle is the first thing the AI checks
Scope discipline is enforced at every decision point
Evidence requirements built into workflow

The Phase 0 investment: ~17 credits (about 1 focused session).
The estimated total investment (Phase 0-3): ~2,000 credits across 7-10 sessions.
The return: Every future session starts with "experienced contributor" knowledge, improving further with each phase.

The Broader Vision: AI as a Real Team Member

This isn't about making AI produce better code in isolation. It's about making AI a real team member — one that:

Understands the project's architecture and respects it
Follows established patterns without being told each time
Communicates with maintainers in appropriate style
Makes decisions consistent with project history
Gets better over time as new patterns are learned

When you onboard a human contributor, you invest days or weeks. The return is years of productive contribution. AI onboarding takes hours. The return is immediate, perpetual, and reusable — the knowledge never degrades, never gets forgotten, and can be shared with every contributor who uses AI assistance.

Getting Started

Minimal approach (30 minutes):

Ask your AI assistant:

Read all my project documentation and create a steering system with:
1. Core principles - Non-negotiable project rules
2. Quick reference - Common scenarios with guidance
3. Pattern index - Keyword lookup and gap tracking

Validate by simulating one realistic contribution scenario.

Full approach (Kiro Power):

Create a Power following the Kiro Power format:

Write a POWER.md with frontmatter, core principles, and steering routing
Add steering/ files for on-demand knowledge modules
Push to GitHub and install via the Kiro Powers panel

The key insight: Your AI assistant's quality ceiling isn't its model capability — it's how well it understands your specific project. Onboarding closes that gap.

Conclusion: Work in Progress

Spec-driven development taught me to think before we code. AI onboarding extends that principle: think about what your AI needs to know before it contributes.

We completed Phase 0 and packaged it as a Kiro Power. We're now gathering real-world experience using it during actual development. The questions we're exploring:

Does the guide reduce maintainer feedback cycles in practice?
Which gaps surface first during real contributions?
Is the modular architecture valuable, or is the core system sufficient for most work?
When does the investment in Phase 1+ pay for itself?

Based on these experiences, we'll decide whether and when to proceed with deeper phases. The phased/agile approach means we can stop at any point with a useful deliverable — there's no all-or-nothing commitment.

The result isn't just better AI output. It's a reusable knowledge artifact that benefits every contributor — human or AI (but mainly for AI nowadays) — who works on your project. It's institutional knowledge preservation. It's accelerated onboarding. It's quality at scale.

Your AI pair programmer is ready to learn. The question is whether you'll invest in teaching it your project's way of working, or keep accepting "works but doesn't belong" code forever.

Links & Resources

JavaParser Contributor Power: github.com/verhasi/kiro-powers
Kiro Powers documentation: kiro.dev/docs/powers/create
JavaParser project: github.com/javaparser/javaparser
Kiro: kiro.dev

This methodology was developed during contributions to the JavaParser open source project using Kiro CLI. The approach is language-agnostic and applicable to any codebase with established conventions. Follow-up posts will share what we learn from real-world usage and deeper onboarding phases.

DEV Community: Istvan Verhas

Simplify Java and Spring Boot Migration with OpenRewrite (2026 Refresh)

How This Post Was Created

Challenges of Migration

OpenRewrite

How does it work?

⚠️ New in 2026: the Code Genome Project repository

Practice

Codebase

1) pom.xml

2) UserController.java

3) UserService.java

4) UserRepository.java

5) User.java

6) UserControllerTest.java

Manual migration

Migration with OpenRewrite

Add the OpenRewrite plugin

Choose the recipes for migration

Already partway there? The same config still works

Preview the migration

Apply the migration

Verify it actually works

Limitations

Summary

Credits

References

Happy 8th Birthday, JEP 8209434 — Here's Your Preview Implementation

What JEP 8209434 Proposes

Why Wait?

The Preprocessor

The Expression Form (->)

The Method Reference Form (=)

Real-World Example: JDK's UnmodifiableCollection

How It Works

API

Works on Any Java Version

What's Next

Try It

OpenAPI Spec Validation in Maven Is Now a First-Class Citizen (v7.24.0)

The Problem

The Solution: validate Goal

Why This Matters

1. Fail-Fast CI/CD

2. No Unnecessary Work

3. Bulk Validation

4. Eclipse/m2e Integration

Behavior

The Bigger Picture: Contract-First Development

Try It

Links

Onboarding Your AI Pair Programmer: From Spec-Driven Development to Kiro Powers

The Problem Nobody Talks About

The Insight: AI Needs Onboarding Too

Spec-Driven Development Meets AI Memory

The Story: A Real-World Wake-Up Call

The Architecture: Modular Steering System

Memory Efficiency

The Process: Phased Onboarding

Phase 0: Documentation Study (~1 session)

Phase 1: Recent PR Analysis (~2-3 sessions)

Phase 2: Deep Historical Analysis (~3-4 sessions)

Phase 3: Community Integration (~1-2 sessions)

Quality Assurance: How Do You Know It Works?

The Evolution: From Files to Kiro Powers

Real Results (Phase 0)

The Broader Vision: AI as a Real Team Member

Getting Started

Conclusion: Work in Progress

Links & Resources

The Expression Form (`->`)

The Method Reference Form (`=`)

The Solution: `validate` Goal