Upgrade to Java 17 and Spring Boot 3.2.5

[devin-ai-integration]

Summary

Upgrades the project from Java 11 / Spring Boot 2.6.3 to Java 17 / Spring Boot 3.2.5. This touches build configuration, all Java source files using javax APIs, the Spring Security configuration, and several libraries with breaking API changes.

Build & tooling:

• Java 11 → 17, Gradle 7.4 → 8.7, Spring Boot 2.6.3 → 3.2.5
• Spring dependency-management 1.0.11 → 1.1.5, Spotless 6.2.1 → 6.25.0
• CI workflow updated to JDK 17 and actions v4

Dependency upgrades with API migration:

• MyBatis Spring Boot Starter 2.2.2 → 3.0.3
• Netflix DGS 4.9.21 → 7.6.0 (codegen 5.0.6 → 6.2.1) — PageInfo switched from graphql.relay.DefaultPageInfo to codegen-generated io.spring.graphql.types.PageInfo; DataFetcherExceptionHandler.onException() → handleException() returning CompletableFuture
• JJWT 0.11.2 → 0.12.5 — parserBuilder() → parser().verifyWith(), setSubject/setExpiration → subject/expiration, parseClaimsJws → parseSignedClaims, getBody → getPayload, key construction via Keys.hmacShaKeyFor()
• Rest Assured 4.5.1 → 5.4.0
• SQLite JDBC 3.36.0.3 → 3.45.3.0

Namespace migration: All javax.validation, javax.servlet, javax.annotation imports → jakarta.* (~20 files). javax.crypto correctly left as-is (JDK class).

Spring Security 6: Removed WebSecurityConfigurerAdapter, converted to SecurityFilterChain bean with lambda DSL, authorizeRequests → authorizeHttpRequests, antMatchers → requestMatchers.

Spring Boot 3: handleMethodArgumentNotValid signature updated (HttpStatus → HttpStatusCode).

Merge note

.github/workflows/gradle.yml was deleted on master but this PR re-introduces it (updated for JDK 17 / actions v4). Reviewer should confirm whether CI via this workflow is still desired.

Review & Testing Checklist for Human

• CI workflow existence: gradle.yml was deleted on master. This PR keeps the file (updated for Java 17). Verify this is intentional — if CI has moved elsewhere, this file may need to be removed from the PR.
• JJWT key size / algorithm change: Keys.hmacShaKeyFor(secret.getBytes()) auto-selects HMAC algorithm by key length (≥32 bytes → HS256, ≥48 → HS384, ≥64 → HS512). The old code hardcoded HS512. Verify jwt.secret in application properties is ≥64 bytes if HS512 is intended, otherwise existing tokens will be incompatible.
• Security filter chain equivalence: Verify authorization rules in WebSecurityConfig are functionally equivalent — especially that GET /articles/feed (authenticated) is matched before GET /articles/** (permitAll). The rule ordering in the lambda DSL must match the old chain. Run a manual smoke test of authenticated and unauthenticated endpoints.
• DGS PageInfo field mapping: buildArticlePageInfo / buildCommentPageInfo now use PageInfo.newBuilder() with .hasPreviousPage() / .hasNextPage(). Confirm these match the GraphQL schema field names and that pagination queries return correct cursor info.
• ./gradlew bootRun smoke test: Unit tests pass locally, but verify the app starts and serves requests end-to-end (REST + GraphQL).

Recommended test plan: Run ./gradlew bootRun, hit a few REST endpoints (GET /articles, POST /users, GET /articles/feed with auth), and run a GraphQL query with pagination to confirm PageInfo fields are populated correctly.

Notes

• The GraphQLCustomizeExceptionHandler now returns CompletableFuture<DataFetcherExceptionHandlerResult> (DGS 7.x async interface). The implementation wraps results with CompletableFuture.completedFuture() so behavior is effectively synchronous — this is the correct pattern for DGS 7.x.
• Snyk security check reports 1 failure (not a required check). This is likely a pre-existing vulnerability in a transitive dependency, not introduced by this upgrade.
• Work was parallelized across 4 child sessions (build.gradle, javax→jakarta, Spring Security, app properties) then integrated and fixed in a final pass.

Link to Devin session: https://app.devin.ai/sessions/6b6e368662274e11802ca77645e8d6fb
Requested by: @scottyandrade99

---

[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 and CI monitoring

[devin-ai-integration]

Devin Review found 1 potential issue.

View 7 additional findings in Devin Review.

[devin-ai-integration]

🟡 Stale closure in comment state updates causes deleted comments to reappear

Both handleCommentDelete and handleCommentSubmit in ArticleView.tsx use comments directly from the render closure instead of the functional form of setComments. If a user deletes two comments in quick succession (before the API calls complete), the second setComments call uses the stale comments array from the original render, overwriting the first deletion. For example: if comments = [A, B, C] and the user deletes A then B, both handlers close over the same [A, B, C] array. When A's API call completes, setComments([B, C]) is correct. But when B's API call completes, setComments([A, C]) is called (from the stale closure), incorrectly bringing A back. The same issue applies to handleCommentSubmit at line 103 — setComments([newComment, ...comments]) can lose a previously added comment.

Suggested change

	setComments(comments.filter(comment => comment.id !== commentId));
	setComments(prevComments => prevComments.filter(comment => comment.id !== commentId));

---

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

[devin-ai-integration]

This file (frontend/src/pages/ArticleView.tsx) is not part of the Java 17 / Spring Boot 3 upgrade changes in this PR — it's a pre-existing React frontend file that appears in the diff due to merge-base differences. The stale closure observation is valid but out of scope for this PR.