Upgrade to Java 21 + Spring Boot 3.5 (javax→jakarta, Security 6, DGS/MyBatis majors)

[devin-ai-integration]

Summary

Upgrades the app from Java 11 + Spring Boot 2.6.3 to Java 21 + Spring Boot 3.5.3, including the framework-major "big bang" (javax→jakarta, Spring Security 6, graphql-java/DGS/MyBatis majors) and a modernized build/test toolchain. Built up on the integration branch in dependency order — Phase 0 (independent dep pre-work) → Phase 1 (build config) → Phase 2 (framework big bang) → Phase 3 (test/E2E finish) — each phase merged and gated.

Verification (Java 21): ./gradlew clean test spotlessCheck → BUILD SUCCESSFUL, 68 tests, 0 failures, spotless clean. CI runs clean test -x jacocoTestCoverageVerification. The jacocoTestCoverageVerification gate (~0.31 instruction ratio) is pre-existing on main and already excluded from CI; it was left untouched (not weakened). The seleniumTest E2E smoke suite ran green on real Chrome 137.

Build / toolchain

• Gradle wrapper 7.4 → 8.10.2; sourceCompatibility/targetCompatibility 11 → 21.
• org.springframework.boot 2.6.3 → 3.5.3, io.spring.dependency-management 1.0.11 → 1.1.7.
• CI gradle.yml JDK 11 → 21 (zulu).

Framework (javax → jakarta, Security 6)

• javax.validation.*/javax.servlet.* → jakarta.* across all sources (javax.crypto.* stays JDK). No explicit javax.validation jar on the classpath, so @Valid resolves to the jakarta provider — the HTTP 422 controller tests pass (dual-provider silent-skip pitfall avoided).
• WebSecurityConfig: dropped WebSecurityConfigurerAdapter for a @Bean SecurityFilterChain lambda DSL:

http.csrf(disable).cors(...).sessionManagement(STATELESS)
    .exceptionHandling(authenticationEntryPoint = HttpStatusEntryPoint(UNAUTHORIZED))
    .authorizeHttpRequests(... requestMatchers(...) ...)   // was authorizeRequests()/antMatchers()
    .addFilterBefore(jwtTokenFilter(), UsernamePasswordAuthenticationFilter.class)

same route rules; PasswordEncoder/CorsConfigurationSource beans kept.

Framework-coupled dependencies

• DGS/GraphQL: codegen 5.0.6 → 7.0.3; pinned graphql-dgs-spring-boot-starter:4.9.21 → DGS platform BOM graphql-dgs-platform-dependencies:9.2.2 + unversioned (classic) starter. codegen 7 now generates its own PageInfo, so typeMapping = ["PageInfo": "graphql.relay.PageInfo"] keeps datafetcher code unchanged. graphql-java 22 changed DataFetcherExceptionHandler.onException(...) → handleException(...) returning CompletableFuture — GraphQLCustomizeExceptionHandler rewritten accordingly.
• MyBatis starter + starter-test 2.2.2 → 3.0.4; Flyway BOM-managed (runs the SQLite migrations in tests with no extra module).
• CustomizeExceptionHandler.handleMethodArgumentNotValid: Spring 6 param HttpStatus → HttpStatusCode.
• Phase 0 (already on the branch): joda-time → java.time.Instant; jjwt 0.11.2 → 0.12.6 (parser()/verifyWith()/parseSignedClaims, Keys.hmacShaKeyFor); sqlite-jdbc 3.46.0.0; spotless 6.25.0; jacoco 0.8.12.

Tests / E2E

• REST-Assured 4.5.1 → 5.5.1 (all 4 artifacts); removed mockito-inline:4.0.0 (Mockito 5 from spring-boot-starter-test is inline by default); @MockBean → @MockitoBean across the 9 API test classes.
• Selenium BOM-managed 4.31.0 (dropped the misleading explicit 4.15.0 pin); webdrivermanager 5.6.2 → 5.9.2; testng 7.8.0 → 7.10.2; httpclient5 BOM-managed (Boot 3.5 HttpClientAutoConfiguration needs TlsSocketStrategy). seleniumTest smoke suite passes on Chrome 137.

Note

• Spotless target now excludes build/** (Gradle 8 strict task validation flags a spotless input overlapping another task's output dir).

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

---

[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]

🟡 buildCommentResult uses getCreatedAt() for updatedAt instead of getUpdatedAt()

In CommentDatafetcher.buildCommentResult(), the updatedAt field is populated using comment.getCreatedAt() instead of comment.getUpdatedAt(). The CommentData class (src/main/java/io/spring/application/data/CommentData.java:19-20) has separate createdAt and updatedAt fields, and the database schema (src/main/resources/db/migration/V1__create_tables.sql:47-48) has distinct created_at and updated_at columns. While this is a pre-existing issue (the old Joda code had the same bug), the PR touched these lines during the migration and carried the bug forward.

---

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

[devin-ai-integration]

Good catch, and confirmed correct — updatedAt should use getUpdatedAt() (as ArticleDatafetcher does). However this is a pre-existing bug on main, not introduced here: the original Joda code was .updatedAt(ISODateTimeFormat.dateTime().withZoneUTC().print(comment.getCreatedAt())). The migration deliberately preserves wire-format/behavior (source-parity), so the joda→java.time rewrite of these lines kept the identical (buggy) behavior rather than silently changing the API response inside a large framework-upgrade PR.

Leaving it as-is to keep this PR behavior-neutral; recommending a separate small follow-up PR to fix getCreatedAt() → getUpdatedAt() here (no test currently locks this — CommentsApiTest constructs CommentData with createdAt in both slots — so a fix should add a test asserting updatedAt != createdAt).

[devin-ai-integration]

🚩 Custom Instant serializer may conflict with auto-configured JavaTimeModule

The old code registered a custom serializer for Joda's DateTime.class, which had no conflict with any auto-configured Jackson module. The new code at src/main/java/io/spring/JacksonCustomizations.java:25 registers a custom serializer for Instant.class, which conflicts with the InstantSerializer from jackson-datatype-jsr310's JavaTimeModule (auto-configured by Spring Boot 3). In practice, Spring Boot registers @Bean modules after auto-discovered ones, so the custom serializer should take precedence and produce the expected yyyy-MM-dd'T'HH:mm:ss.SSS'Z' format. However, this ordering is implicit and could break if module registration order changes in a future Spring Boot version. A more robust approach would be to configure JavaTimeModule's serialization format or explicitly disable JavaTimeModule auto-configuration.

---

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

[devin-ai-integration]

The custom @Bean Module serializer does take precedence and the wire format is verified by a passing test: ArticleApiTest.should_get_article_success asserts article.createdAt equals DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'")...format(time) (ArticleApiTest.java:78-83). That test is green in this PR, so the custom InstantSerializer is winning over JavaTimeModule's default Instant handling and the yyyy-MM-dd'T'HH:mm:ss.SSS'Z' contract is preserved.

Agreed the precedence is implicit. Since behavior is currently correct and test-locked, I'm leaving it for this migration PR; a reasonable future hardening (separate from this upgrade) would be to set the format on JavaTimeModule / JacksonProperties or register the serializer via Jackson2ObjectMapperBuilderCustomizer so the ordering is explicit rather than relying on @Bean-after-autoconfig registration.

[devin-ai-integration]

Devin Review found 1 new potential issue.

[devin-ai-integration]

🚩 Flyway SQLite support may require additional dependency with Spring Boot 3.5

Spring Boot 3.5.0 ships with Flyway 10+ which modularized database-specific support into separate artifacts. The build only declares implementation 'org.flywaydb:flyway-core' at build.gradle:65. If the bundled Flyway version requires org.flywaydb:flyway-database-sqlite for SQLite support, the application would fail at startup. This depends on the exact Flyway version managed by the Spring Boot 3.5.0 BOM — if it's Flyway 10+, SQLite support was moved out of core. This should be verified by running the application or tests against the SQLite database.

---

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

[devin-ai-integration]

Verified — this does not apply to this project's usage. The Boot 3.5 BOM resolves flyway-core to 11.7.2 (no flyway-database-sqlite on the classpath), and SQLite migrations still run successfully:

• RealworldApplicationTests.contextLoads is @SpringBootTest with the default profile, so it uses spring.datasource.url=jdbc:sqlite:dev.db (file-based) and boots the full context — which triggers Flyway auto-configuration to apply V1__create_tables.sql + V2__seed_data.sql at startup. That test passes (tests="1" failures="0" errors="0"), exercising the exact app-startup migration path you flagged.
• The MyBatis repository tests (DbTestBase → @MybatisTest, @ActiveProfiles("test"), in-memory jdbc:sqlite::memory:, spring.flyway.target=1) also apply V1 via Flyway and pass (e.g. ArticleRepositoryTransactionTest, MyBatisArticleRepositoryTest).

So Flyway 11 handles SQLite here without the separate module, and the green @SpringBootTest context-load test will catch any regression if the managed Flyway version ever drops bundled SQLite support. No change needed.