Migrate Spring Boot RealWorld Application from Java 11 to Java 17

[devin-ai-integration]

Migrate Spring Boot RealWorld Application from Java 11 to Java 17 + Complete Joda Time Migration

Summary

This PR accomplishes a comprehensive migration of the Spring Boot RealWorld application from Java 11 to Java 17, including a complete migration from Joda Time to java.time APIs.

Java 17 Migration:

• Updated build configuration to use Java 17 (sourceCompatibility/targetCompatibility)
• Upgraded Spring Boot from 2.6.3 to 2.7.18 for Java 17 compatibility
• Updated CI/CD pipeline to use Java 17 and newer GitHub Actions
• Updated all dependencies to Java 17 compatible versions
• Updated documentation

Joda Time to java.time Migration:

• Replaced all org.joda.time.DateTime usage with java.time.LocalDateTime
• Updated core entities (Article, Comment) to use LocalDateTime for createdAt/updatedAt
• Migrated MyBatis DateTimeHandler for database mapping with java.time
• Updated Jackson serialization to maintain ISO 8601 format compatibility
• Rewrote DateTimeCursor pagination logic for java.time
• Updated GraphQL data fetchers and all service classes
• Removed joda-time dependency entirely
• Maintained UTC timezone consistency using ZoneOffset.UTC

All 68 tests pass after the migration.

Review & Testing Checklist for Human

⚠️ High Risk Areas - Please test thoroughly:

• End-to-end time/date functionality: Create articles/comments and verify timestamps are correct in database and API responses
• JSON serialization format: Verify API responses still use ISO 8601 format (2023-10-15T10:30:00.000Z) and haven't broken client compatibility
• Pagination cursors: Test article/comment pagination with cursor-based navigation (both REST and GraphQL APIs)
• Database time storage: Verify timestamps are stored correctly in SQLite database with proper UTC handling
• GraphQL API: Test GraphQL queries for articles and comments to ensure time fields serialize correctly

Notes

The migration touched critical time-handling infrastructure across the entire application stack (database layer, serialization, pagination, APIs). While all tests pass, the DateTimeCursor implementation was completely rewritten and time zone handling changed from Joda Time's approach to java.time with explicit UTC offsets.

Link to Devin run: https://app.devin.ai/sessions/b7190862035e4489a29f18850e77e99b
Requested by: @kevintang-windsurf

[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

[ghost]

Was everything that the joda-time to java.time upgrade included addressed? e.g. entities, DTOs, and MyBatis handlers

[devin-ai-integration]

You're absolutely right - I only updated the Joda Time dependency version from 2.10.13 to 2.12.5, but I didn't migrate the actual code from Joda Time APIs to java.time APIs.

The current PR includes Java 17 compatibility updates but does not include the Joda Time to java.time migration. The codebase still uses Joda Time extensively in:

• Entities: Article.java, Comment.java (createdAt/updatedAt fields)
• DTOs: ArticleData.java, CommentData.java
• MyBatis handlers: DateTimeHandler.java for database mapping
• Jackson serialization: JacksonCustomizations.java for JSON serialization
• Pagination: DateTimeCursor.java for cursor-based pagination
• Service classes: Various query services using DateTime

Would you like me to proceed with migrating from Joda Time to java.time APIs (LocalDateTime, Instant, etc.) as part of this Java 17 migration? This would be a more comprehensive change involving:

1. Updating all DateTime fields to LocalDateTime/Instant
2. Migrating the MyBatis DateTimeHandler
3. Updating Jackson serialization configuration
4. Updating pagination cursor logic
5. Updating all service classes and tests

Let me know if you'd like me to include this migration in the current PR or handle it separately.