Upgrade Java 11 → 21 and Spring Boot 2.6.3 → 3.2.5

[devin-ai-integration]

Summary

Comprehensive upgrade from Java 11 to Java 21, requiring a full migration from Spring Boot 2.6.3 to 3.2.5 and all associated dependency and API changes.

Build & Dependencies

• Java: 11 → 21 (sourceCompatibility/targetCompatibility)
• Gradle wrapper: 7.4 → 8.7
• Spring Boot: 2.6.3 → 3.2.5
• Spring dependency-management: 1.0.11.RELEASE → 1.1.4
• DGS GraphQL: graphql-dgs-spring-boot-starter:4.9.21 → graphql-dgs-spring-graphql-starter:8.5.0
• DGS codegen plugin: 5.0.6 → 6.0.3
• MyBatis Spring Boot: 2.2.2 → 3.0.3
• JJWT: 0.11.2 → 0.12.5
• SQLite JDBC: 3.36.0.3 → 3.45.3.0
• Rest Assured: 4.5.1 → 5.4.0
• Joda-Time: 2.10.13 → 2.12.7
• Spotless: 6.2.1 → 6.25.0

Code Migration

• Jakarta namespace: All javax.validation.* → jakarta.validation.*, javax.servlet.* → jakarta.servlet.* across 20 files
• Spring Security: Removed WebSecurityConfigurerAdapter, migrated to SecurityFilterChain bean with lambda DSL (antMatchers → requestMatchers)
• JJWT API: Migrated to 0.12.x API — Keys.hmacShaKeyFor(), .subject(), .expiration(), .parseSignedClaims(), .getPayload()
• DGS exception handler: onException() → handleException() returning CompletableFuture<DataFetcherExceptionHandlerResult>
• GraphQL PageInfo: graphql.relay.DefaultPageInfo → generated io.spring.graphql.types.PageInfo builder
• ResponseEntityExceptionHandler: HttpStatus → HttpStatusCode parameter type

CI/CD

• GitHub Actions: actions/checkout@v2 → v4, setup-java@v2 → v4, cache@v2 → v4, JDK 11 → 21

Configuration

• Added spring.graphql.schema.locations=classpath:schema/ for DGS 8.x Spring GraphQL integration
• Added spring.graphql.schema.inspection.enabled=false to prevent Spring GraphQL auto-configuration conflict with DGS relay-style connection types

Review & Testing Checklist for Human

• Run ./gradlew clean test with JDK 21 and verify all 68 tests pass
• Start the application with ./gradlew bootRun and verify REST API endpoints work (e.g., POST /users, GET /articles, GET /tags)
• Verify GraphQL endpoint at /graphql works correctly (queries, mutations)
• Verify JWT authentication flow — register user, login, access authenticated endpoints
• Review Spring Security requestMatchers patterns match the original antMatchers behavior

Notes

• javax.crypto.* imports were intentionally not changed — these are JDK core packages, not Jakarta EE
• The Spotless target was narrowed from **/*.java to src/**/*.java to avoid Gradle 8.x task dependency ordering issues with generated sources
• All 68 tests pass locally on JDK 21.0.10

Link to Devin session: https://app.devin.ai/sessions/6e43fc09a064493c8c72a10f4d1cf122
Requested by: @davidbean-hash

---

Devin Review

Status	Commit
⚪ Not started	—

Run Devin Review

💡 Connect your GitHub account to enable automatic code reviews.

---

[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 3 potential issues.

View 8 additional findings in Devin Review.

[devin-ai-integration]

🟡 Stale closure in handleArticleUpdate causes lost favorite state on rapid interactions

The handleArticleUpdate callback closes over the articles array from the render where it was created, rather than using a functional state update. When a user rapidly favorites two different articles, both ArticleCard components' onUpdate callbacks reference the same stale articles array. The second setArticles call overwrites the first, causing the first favorite toggle to be visually lost.

Scenario demonstrating the bug

1. Render: articles = [A, B], handleArticleUpdate captures articles = [A, B]
2. User clicks favorite on A → API call starts
3. User clicks favorite on B → API call starts (same render's callback)
4. A's API resolves → setArticles([A, B].map(…)) → [A', B]
5. B's API resolves → setArticles([A, B].map(…)) (stale!) → [A, B']
6. A's favorite state is lost in the UI

The fix is to use the functional form of setArticles: setArticles(prev => prev.map(…)). The identical bug exists at frontend/src/pages/Profile.tsx:72-74.

Suggested change

	const handleArticleUpdate = (updatedArticle: Article) => {
	setArticles(articles.map(article =>
	article.slug === updatedArticle.slug ? updatedArticle : article
	));
	};
	const handleArticleUpdate = (updatedArticle: Article) => {
	setArticles(prev => prev.map(article =>
	article.slug === updatedArticle.slug ? updatedArticle : article
	));
	};

---

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

[devin-ai-integration]

This file is in the pre-existing frontend/ directory that was added in a previous PR (#2) — not modified by this Java 11→21 upgrade PR. The stale closure suggestion is valid but out of scope for this change.

[devin-ai-integration]

🟡 Stale closure in comment handlers causes lost comment state on concurrent operations

Both handleCommentSubmit and handleCommentDelete close over the comments array instead of using functional state updates. If a comment is added or deleted while another async comment operation is in-flight, the second setComments call uses the stale comments from the closure, overwriting the result of the first operation. For handleCommentDelete, there is no per-comment loading guard, so deleting two comments in quick succession can cause one deletion to be visually reverted (though the server-side deletions succeed).

Suggested change

	const handleCommentSubmit = async (body: string) => {
	if (!slug) return;
	const newComment = await commentsApi.addComment(slug, body);
	setComments([newComment, ...comments]);
	};
	const handleCommentDelete = async (commentId: string) => {
	if (!slug) return;
	await commentsApi.deleteComment(slug, commentId);
	setComments(comments.filter(comment => comment.id !== commentId));
	};
	const handleCommentSubmit = async (body: string) => {
	if (!slug) return;
	const newComment = await commentsApi.addComment(slug, body);
	setComments(prev => [newComment, ...prev]);
	};
	const handleCommentDelete = async (commentId: string) => {
	if (!slug) return;
	await commentsApi.deleteComment(slug, commentId);
	setComments(prev => prev.filter(comment => comment.id !== commentId));
	};

---

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

[devin-ai-integration]

Same as the Home.tsx comment — this file is in the pre-existing frontend/ directory from PR #2, not modified by this Java upgrade. The stale closure fix is valid but out of scope here.

[devin-ai-integration]

🟡 JWT test secret produces HS384 instead of HS512, making expired-token test verify algorithm mismatch

The test secret "123123..." is 60 bytes (480 bits). With the migration from new SecretKeySpec(secret.getBytes(), "HmacSHA512") to Keys.hmacShaKeyFor(secret.getBytes()), the key algorithm changed from HS512 to HS384 (since 480 bits >= 384 but < 512). The should_get_null_with_expired_jwt test uses a hardcoded HS512 token ("alg":"HS512" in header). In jjwt 0.12.x, parsing this HS512 token with an HS384 key throws an algorithm mismatch exception rather than an expiration exception. The test still passes (because all exceptions return Optional.empty()), but it now tests algorithm rejection instead of token expiration. Fix by using a 64+ byte test secret to match the HS512 algorithm.

Suggested change

	jwtService =
	new DefaultJwtService("123123123123123123123123123123123123123123123123123123123123", 3600);
	jwtService =
	new DefaultJwtService("1231231231231231231231231231231231231231231231231231231231231231231231231231231231231231", 3600);

---

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

[devin-ai-integration]

Good catch — the 60-byte secret selects HS384 via Keys.hmacShaKeyFor(), so the hardcoded HS512 expired token test was verifying algorithm mismatch instead of expiration. Fixed in cd86125 by using a 64+ byte secret to ensure HS512 selection.