Upgrading 30+ Open-Source Projects to Java 25 — With an AI Co-Pilot

After launching the Dynamic CDI Test Bean Addon as the first fully AI-created os890 project, the natural next step was putting it to work: upgrading the entire os890 open-source portfolio to Java 25 and modern Jakarta EE.

The Starting Point

Over the years, the os890 GitHub account accumulated 30+ projects — CDI extensions, DeltaSpike add-ons, project templates, and demo applications. Most were stuck on Java 6–8, the javax.* namespace, DeltaSpike 1.x, and JUnit 4. Some hadn't seen a commit in years. They all worked, but they were falling behind the ecosystem.

The Upgrade Scope

Every project received the same treatment:

• Java 25 with maven.compiler.release
• Jakarta EE namespace migration (javax.* → jakarta.*) across all Java sources, XML configs, service files, and persistence descriptors
• DeltaSpike 2.x with adaptation to removed APIs (e.g., ExceptionToCatchEvent, DeltaSpikeLiteral)
• JUnit Jupiter 6 replacing JUnit 4, with all existing assertions preserved
• CDI 4.1 namespace in all beans.xml files
• Test migration from Weld/DeltaSpike test-control to the new Dynamic CDI Test Bean Addon with @EnableTestBeans
• Seven quality plugins: compiler warnings as errors, enforcer (dependency convergence + banned javax.*), checkstyle, Apache RAT license verification, pinned surefire, JaCoCo coverage, and javadoc
• Apache License 2.0 — the official canonical text, verified via an enforcer checksum rule in every build

The Quality Bar

The upgrade wasn't just "make it compile on Java 25." Every project now enforces zero tolerance:

• Zero checkstyle violations (including test sources)
• Zero unapproved license headers (Apache RAT)
• Zero compiler warnings (-Xlint:all with failOnWarning)
• Zero dependency convergence conflicts
• All javax.* dependencies banned via enforcer
• LICENSE file integrity verified by MD5 checksum in every build

If any of these checks fail, the build fails. No exceptions, no suppressions.

Where the AI Co-Pilot Helped

An upgrade like this is conceptually simple but mechanically brutal. Across 30+ projects, you're touching hundreds of files — and every project has its own quirks: multi-module structures, profiles for different containers (TomEE, Weld, OWB), deprecated APIs that disappeared between library versions, and serialization warnings on CDI interceptors that implement Serializable through framework interfaces.

The agentic AI workflow handled the repetitive mechanical work — namespace replacements, dependency version bumps, quality plugin configuration, license headers, Javadoc — while I focused on the decisions that require judgment: whether a logic change is justified by an API removal, whether a @SuppressWarnings("serial") is acceptable on a CDI interceptor, or whether removed test profiles should be restored.

Compared to rule-based migration tools like OpenRewrite, the agentic AI approach was significantly more flexible. In my experience, tools like OpenRewrite tend to handle only the standard cases well — and sometimes only in simple, single-module project structures. Once you hit multi-module builds, container-specific Maven profiles, or APIs that were removed rather than just renamed, those tools hit their limits quickly and you're back to manual work anyway. The agentic AI approach, on the other hand, handled the full complexity: adapting to removed APIs, restructuring test infrastructure, resolving container-specific quirks across different profiles, and making judgment calls about code that couldn't be mechanically migrated. With an AI co-pilot, the conversation was iterative: explain the intent, review the result, course-correct where needed.

Quality was further improved by adding proper README files and Javadoc to every project. Each README now documents the project's purpose, usage, and build instructions — making the repositories approachable again after years of minimal documentation. The Javadoc pass ensured that public APIs are properly documented, and with the Javadoc Maven plugin configured to fail on errors, this standard is enforced in every build going forward.

Some concrete examples where human review caught issues the AI initially missed:

• Tests that were silently removed instead of being upgraded in place
• Logic was silently rewritten instead of being upgraded
• Extra -Xlint suppression flags that violated the quality rules
• Enforcer rules that banned specific javax artifacts instead of using a wildcard pattern
• LICENSE files that looked like Apache 2.0 but were actually paraphrased variants

The Result

All projects now build cleanly on Java 25 with mvn clean verify — including all Maven profiles. Every project has comprehensive tests using the Dynamic CDI Test Bean Addon, proper license files, and a strict quality gate that prevents regressions.

The enforcer checksum rule for the LICENSE file is a small detail I'm particularly happy about. It's one line of XML that guarantees nobody accidentally replaces the canonical Apache 2.0 text with an abbreviated version — something that actually happened during the AI-assisted upgrade and was only caught during review.

Lessons Learned

1. Codify your rules. Writing the upgrade rules in a Markdown file that both the human and the AI could reference eliminated ambiguity. When the AI made a choice that violated a rule, pointing to the specific rule made the correction instant.
2. Verify, don't trust. Every upgrade went through: audit → fix → build all profiles → review → push. The AI is fast at the mechanical work but occasionally takes shortcuts (suppressing warnings instead of fixing them, removing code instead of migrating it).
3. Checksums are underrated. The LICENSE file saga — where every repo had a different "Apache 2.0" text — would have been invisible without comparing MD5 hashes. The enforcer checksum rule now makes this a build-time guarantee.

What's Next

With all projects on a common modern baseline, the next focus is on the projects themselves — new features, better documentation, and exploring what CDI 4.1 makes possible that wasn't feasible before. The quality infrastructure is now solid enough that contributions (human or AI) are held to the same standard automatically.

Disclaimer: This blog post was generated after the upgrade process, based on the interactions and conversations that took place during the upgrades. The upgrades themselves were performed using an agentic AI workflow with human review and approval at every step. All code changes were verified by building and testing before being pushed.