Converting a Spring Boot Project to Helidon with AI

The author builds a lightweight Spring Pets test suite, evaluates three AI‑assisted migration strategies—contextual, incremental and hybrid—using OpenAI GPT‑4o, reports conversion coverage, performance, cost and practical challenges, and shares open‑source tooling for future Java framework migrations.

JakartaEE China Community
JakartaEE China Community
JakartaEE China Community
Converting a Spring Boot Project to Helidon with AI

Migration Test Project

Spring Pets is a trimmed version of Spring Petclinic Rest, containing core features needed for conversion: Spring Data JPA with HSQL, Spring Transactions, Bean Validation, three‑layer architecture, Spring REST Controllers, MapStruct mappers, Jackson JSON binding, Spring MockMVC tests.

Migration Results

Using OpenAI GPT‑4o the entire Spring Pets codebase (except the test module) was converted by commenting out a few dependencies in pom.xml. Converted components:

Data layer: three Spring Data JPA interfaces replaced with CDI + JPA implementations.

Controller layer: three Spring REST controllers rewritten as JAX‑RS resources.

Service layer: one Spring @Service bean rewritten as a CDI bean.

Build: Spring Boot pom.xml adapted to Helidon MP.

Auxiliary: six JPA entities, three MapStruct mappers and three DTOs required only minor adjustments.

Full conversion took about ten minutes, compared with manual effort that would be an order of magnitude longer.

Migration Process

Model Selection

Tested several models. GPT‑4o gave the highest quality output at a cost of a few cents per iteration. GPT‑4o‑mini was cheaper with acceptable quality. Locally hosted models (e.g., Qwen Coder via LM Studio) were free but produced poorer conversions.

Migration Schemes

Contextual Migration Provide the whole project as context; the model decides conversion strategy. Enables structural changes and file additions/removals but quickly becomes resource‑intensive as prompts grow.

Incremental Migration Process files one by one. Steps: (1) identify file type, (2) send file with a type‑specific prompt to the model. Implemented a converter (GitHub) that first used JavaParser for classification, later replaced by an AI classifier with the following prompt:

Classify the file based on the following criteria:

1. POM_XML: File name is `pom.xml`.
2. REST_CONTROLLER: Java class annotated with @RestController.
3. REPOSITORY: Java interface or class annotated with @RepositoryDefinition or extending Repository/CrudRepository.
4. ENTITY: Java class annotated with @Entity, @MappedSuperclass, @Table, or @Id.
5. SPRING_BEAN: Java class annotated with @Service, @Component, @Bean, or @Configuration.
6. PLAIN_JAVA: Java class, interface, or record that doesn't meet any other criteria.
7. UNIDENTIFIED: File is not a Java file or doesn't match any of the above criteria.

Output only the classification (one of the above).

This method works with any model, requires minimal prompt changes, and keeps conversion costs low.

Hybrid Migration Theoretical combination of contextual and incremental approaches; would retain global context while allowing fine‑grained control, but inherits the high resource consumption of the contextual scheme and has not been empirically validated.

Pros and Cons

Contextual Migration

Comprehensive project understanding.

Supports structural adjustments and file add/remove.

High resource usage and longer processing time.

Local models struggle with complexity.

Incremental Migration

Low resource demand.

Compatible with locally hosted models.

Good conversion quality.

Cannot dynamically add or remove files.

Requires carefully crafted prompts.

Challenges

Effective AI‑assisted migration depends on precise, unambiguous prompts. Issues encountered include the model returning code wrapped in Markdown blocks, requiring explicit instructions to suppress them. Model nondeterminism produced malformed outputs in roughly 5 % of runs. Additional hurdles: cost management (≈ 15 ¢ per GPT‑4o run), token‑per‑minute limits, and legal considerations of model licenses.

Conclusion

AI can dramatically reduce effort for framework migrations. GPT‑4o currently offers the best results; future model improvements may make full‑context migration more feasible. The techniques are applicable beyond Spring‑to‑Helidon, e.g., migrating legacy javax.* Java EE codebases to Jakarta EE.

References

Spring Pets – https://github.com/m0mus/spring-pets

Contextual Converter – https://github.com/m0mus/ai-converter-ctx

Incremental Converter – https://github.com/m0mus/ai-converter-inc

JavaMicroservicesSpring BootGPT-4oAI migrationHelidon
JakartaEE China Community
Written by

JakartaEE China Community

JakartaEE China Community, official website: jakarta.ee/zh/community/china; gitee.com/jakarta-ee-china; space.bilibili.com/518946941; reply "Join group" to get QR code

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.