App Modernization: Java 11 → 21, Spring Boot 2.6.3 → 3.4.4

[devin-ai-integration]

Summary

Major version upgrade from Java 11 / Spring Boot 2.6.3 to Java 21 / Spring Boot 3.4.4, done in 6 verified layers. Each layer committed independently and verified against ./gradlew clean test spotlessCheck. All 68 tests pass on Java 21.

Why 3.4.4 instead of 3.5.x: Spring Boot 3.5.0's spring-graphql:1.4.0 requires java-dataloader with DataLoaderOptions$Builder, which conflicts with DGS 9.1.3's strictly [3.3.0] constraint. 3.4.4 is the latest Boot 3 release compatible with the DGS 9.x ecosystem.

Layer 1 — Build Config

Gradle 7.4→8.12, sourceCompatibility/targetCompatibility 11→21, Spring Boot plugin 2.6.3→3.4.4, dependency-management 1.0.11→1.1.7, Spotless 6.2.1→6.25.0, JaCoCo 0.8.12. Removed explicit javax.validation:validation-api (Boot 3 provides jakarta.validation-api transitively). Spotless target narrowed to src/**/*.java to avoid Gradle 8 implicit-dependency warnings with generated sources.

Layer 2 — Namespace Migration

javax.validation.*→jakarta.validation.*, javax.servlet.*→jakarta.servlet.* across 19 source files.

Layer 3 — Security Config

// before: extends WebSecurityConfigurerAdapter
// after:
@Bean SecurityFilterChain securityFilterChain(HttpSecurity http) {
  http.csrf(csrf -> csrf.disable())
      .authorizeHttpRequests(auth -> auth
          .requestMatchers(HttpMethod.OPTIONS).permitAll()  // was antMatchers
          .requestMatchers("/graphql").permitAll()
          ...);
}

CustomizeExceptionHandler.handleMethodArgumentNotValid signature updated for HttpStatusCode (Boot 3).

Layer 4 — Infrastructure

• jjwt 0.11→0.12: Jwts.builder().subject().expiration().signWith(key), Jwts.parser().verifyWith(key).build().parseSignedClaims(). Key padded to 64 bytes for Keys.hmacShaKeyFor() minimum.
• joda-time→java.time: DateTime→OffsetDateTime across domain entities (Article, Comment), data classes, query services. Custom DateTimeHandler (MyBatis TypeHandler) rewritten for OffsetDateTime. DateTimeCursor uses Instant/OffsetDateTime. JacksonCustomizations serializer uses DateTimeFormatter.ISO_OFFSET_DATE_TIME.
• MyBatis 2.2→3.0.4: starter aligned with Boot 3.

Layer 5 — DGS GraphQL 4.x → 9.x

graphql.relay.DefaultPageInfo→DGS-generated io.spring.graphql.types.PageInfo (builder API). DataFetcherExceptionHandler.onException→handleException returning CompletableFuture<DataFetcherExceptionHandlerResult>. Platform BOM graphql-dgs-platform-dependencies:9.1.3 + eachDependency resolution strategy to align graphql-java:22.3 / java-dataloader:3.3.0 with DGS codegen 5.12.4.

Layer 6 — Test Dependencies

REST-Assured 4.5→5.5, Selenium WebDriverWait(driver, long)→WebDriverWait(driver, Duration), httpclient5 version managed by Boot (was explicit 5.2.1, conflicted with Boot-managed version causing TlsSocketStrategy ClassNotFoundException). Test fixtures updated for OffsetDateTime.

Verification

./gradlew clean test spotlessCheck -x jacocoTestCoverageVerification → BUILD SUCCESSFUL
68 tests passed, 0 failed

Note: JaCoCo coverage verification (80% threshold) was already failing on the baseline main branch (0% coverage ratio due to class mismatch) — not a regression introduced by this PR.

Link to Devin session: https://partner-workshops.devinenterprise.com/sessions/e99d31e33ea14a2ab366ca4338bfb7d4
Requested by: @bsmitches

---

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[devin-ai-integration]

Devin Review found 2 potential issues.

[devin-ai-integration]

🚩 Flyway + SQLite may require additional dependency with Flyway 10.x

Spring Boot 3.4.4 manages Flyway 10.x, which modularized database support. The build only declares implementation 'org.flywaydb:flyway-core' (build.gradle:77), but the application uses SQLite (application.properties:1 — jdbc:sqlite:dev.db). In Flyway 10+, database-specific support was extracted into separate modules. SQLite may require org.flywaydb:flyway-community-db-support or a similar module. Without it, the application could fail at startup with a "No database found to handle jdbc:sqlite" error. I could not verify the exact Flyway version managed by Spring Boot 3.4.4 or whether SQLite is still bundled in core, so this needs investigation.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

Investigated — this is not an issue for this project. Spring Boot 3.4.4 manages Flyway 10.22.x, and the Flyway 10.x modularization extracted support for commercial databases into separate modules. SQLite support remains in flyway-core for community databases. All 68 tests pass including the ones that exercise Flyway migrations against the SQLite dev.db, confirming that the current flyway-core dependency is sufficient.

[devin-ai-integration]

Devin Review found 1 new potential issue.

[devin-ai-integration]

🚩 Static mutable Calendar instance shared across threads in DateTimeHandler

The UTC_CALENDAR at line 19 is a static final Calendar instance shared by all threads. Calendar is mutable and not thread-safe — JDBC drivers may call mutating methods like set() or clear() on it during getTimestamp/setTimestamp calls, potentially causing race conditions under concurrent requests. This is a pre-existing issue (not introduced by this PR), but worth noting since it wasn't addressed during the migration. A safer approach would be to create a new Calendar instance per call, or use ThreadLocal<Calendar>.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

Agreed this is a valid thread-safety concern, but as noted it's pre-existing behavior carried over from the original joda-time DateTimeHandler — not a regression from this migration. Fixing it would be a separate improvement outside the scope of this upgrade PR. A follow-up could either create a new Calendar per call or switch to Timestamp.from(instant) / Timestamp.valueOf(localDateTime) which avoids Calendar entirely.