feat: upgrade to Java 17 (--release 17)

[tobydrinkall]

Summary

Upgrades this demo from Spring Boot 2.0.2.RELEASE / Java 8 to Spring Boot 2.7.18 / Java 17, keeping the javax.* namespace (no Jakarta migration). Both the Maven and Gradle builds are upgraded in lock-step and each produces an equivalent bootable jar.

Dependency alignment (deliberate decision): the pom previously declared starter-jdbc + h2 + properties-migrator, while Gradle declared only starter-web. Both builds are now aligned on starter-web (+ starter-test), dropping starter-jdbc/h2. This also sidesteps the H2 1.x -> 2.1.214 breaking change.

Source change (deviation from the "no source changes" expectation): the task brief stated the source uses neither JDBC nor H2, but Application.java actually did:

• an @Autowired JdbcTemplate CommandLineRunner that created/populated a customers table (requires jdbc + h2), and
• a RestTemplate fetch of http://gturnquist-quoters.cfapps.io/api/random (a long-dead host) executed during startup, which would throw and fail the boot regardless of Java version.

To honor the drop-jdbc/h2 decision and get a clean smoke test, Application.java is reduced to a plain @SpringBootApplication that starts the context and prints the bean names. The REST endpoints (/topic, etc.) are unaffected.

 pom.xml       packaging pom->jar; parent 2.0.2.RELEASE->2.7.18;
               java.version 1.8->17 + maven.compiler.release 17;
               - starter-jdbc, - h2, - properties-migrator; + starter-test
 build.gradle  buildscript{} -> plugins DSL (org.springframework.boot 2.7.18,
               io.spring.dependency-management 1.0.15.RELEASE, java);
               compile/testCompile -> implementation/testImplementation;
               bootJar{ baseName/version } -> { archiveBaseName/archiveVersion };
               sourceCompatibility/targetCompatibility 1.8 ->
                 java{ toolchain{ languageVersion = JavaLanguageVersion.of(17) } }
                 + tasks.withType(JavaCompile){ options.release = 17 }
 wrappers      Gradle 4.6 -> 7.6.4 (regenerated wrapper jar + scripts); Maven -> 3.9.6

The spring-boot-properties-migrator was kept during smoke-testing to surface renamed Boot 2.0->2.7 properties; it reported nothing (the only property, server.port, is commented out in application.properties), and was removed before finalising, as instructed.

Verification

There is no CI and no test suite in this repo, so verification is compile + package + smoke only. All commands were run under Temurin/OpenJDK 17.0.13, Maven 3.9.6, Gradle 7.6.4:

• ./mvnw -B clean package → BUILD SUCCESS, produces target/gs-spring-boot-0.1.0.jar.
• ./gradlew clean build → BUILD SUCCESSFUL, produces build/libs/gs-spring-boot-0.1.0.jar.
• Smoke test (both jars, separately): java -jar <artifact> → Started Application on port 8080, then curl localhost:8080/topic → HTTP 200 returning the topics JSON array.

Residual risks / not verified

• No automated tests exist; correctness beyond boot + /topic was not exercised.
• Build-environment workaround (not committed): Maven Central was returning HTTP 429, so a local mirror (~/.m2/settings.xml for Maven, ~/.gradle/init.gradle for Gradle) was used to fetch dependencies. This does not affect the repo — default mavenCentral() remains configured in both builds.
• The removed dead-URL quote fetch and JDBC demo code are gone rather than ported; if that behaviour is wanted it should be reintroduced against a live data source.
• Pre-existing committed build artefacts (.idea/, *.iml, target/) were left untouched, per the brief.

Link to Devin session: https://app.devin.ai/sessions/5601a58ca8384f2f84a1243a2753399d
Requested by: @tobydrinkall

---

Devin Review

Status	Commit
⚪ Not started	—

Run Devin Review

---

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

[devin-ai-integration]

📝 Info: Maven wrapper distribution bumped but wrapper script/jar left at 3.3.9 era

.mvn/wrapper/maven-wrapper.properties now points at Maven 3.9.6, but mvnw/mvnw.cmd and the committed .mvn/wrapper/maven-wrapper.jar (49 KB, 0.4.x era) were not regenerated, and the properties file still has no wrapperUrl. It works because the jar is committed and simply downloads whatever distributionUrl says, but a full mvn wrapper:wrapper -Dmaven=3.9.6 regeneration would keep the wrapper self-consistent (and archive.apache.org is rate-limited/slower than repo1.maven.org for distribution downloads).

---

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

[devin-ai-integration]

Accurate. The committed wrapper jar is a version-agnostic bootstrapper that just downloads whatever distributionUrl points at, so it works as-is. I switched to archive.apache.org specifically because repo1.maven.org was returning HTTP 429 during this session; archive.apache.org is the canonical, reliably-available mirror. A full mvn wrapper:wrapper -Dmaven=3.9.6 regeneration (which would also refresh the jar and add wrapperUrl) is a reasonable follow-up but wasn't required to get both builds green.

[devin-ai-integration]

📝 Info: Dead model classes left behind after removing JDBC/RestTemplate demo code

hello.model.Customer, hello.model.Quote and hello.model.Value were only referenced by the removed CommandLineRunner/RestTemplate code in Application.java; they are now unreachable dead code. I verified no other source file references them or JdbcTemplate/RestTemplate, so dropping spring-boot-starter-jdbc/h2 does not break compilation of the remaining controllers/services — but the leftover models are worth deleting for clarity.

---

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

[devin-ai-integration]

Confirmed — Customer, Quote, and Value are now only self-referential (Quote -> Value) with no other usages, so they're dead after removing the JDBC/RestTemplate demo code, and dropping starter-jdbc/h2 doesn't break compilation. I've left them in place because this is a Java-8-features demo repo where the model POJOs are illustrative content; deleting them is a scope/intent call I'd rather leave to the maintainer. Happy to remove them if preferred.

[devin-ai-integration]

📝 Info: starter-test added to both builds with no test sources; JUnit Platform config relies on the Boot plugin

spring-boot-starter-test is now declared in both pom.xml and build.gradle, but there is no src/test directory, so nothing is exercised. Note the Gradle side does not add test { useJUnitPlatform() }; that is fine only because the Spring Boot Gradle plugin (>=2.2) configures Test tasks for the JUnit Platform. If the Boot plugin were ever removed/downgraded, JUnit 5 tests would silently not run.

---

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

[devin-ai-integration]

Correct that there are no test sources yet — starter-test was added per the task's build-alignment requirement so a src/test suite can be dropped in without further build changes. Agreed the Gradle JUnit Platform config is implicit via the Spring Boot plugin (>=2.2); if tests are ever added and the Boot plugin is decoupled, I'd add an explicit test { useJUnitPlatform() }. Not adding it now to keep the diff minimal.

[devin-ai-integration]

🔍 Boot 2.0 -> 2.7 behavioural changes not exercised beyond /topic

Upgrading to Boot 2.7 brings changes that the compile+/topic smoke test would not surface: circular-reference beans are rejected by default since 2.6, and Spring MVC path matching/trailing-slash handling changed. Existing mappings such as /topic/{id} versus /topic/string/operation and /topic/minimum/length/{minLength} in src/main/java/hello/controller/TopicController.java and HelloController.java still resolve by pattern specificity, and TopicService.getTopicWithId (src/main/java/hello/service/TopicService.java:37) still throws NoSuchElementException for unknown ids (pre-existing). Worth manually hitting the other endpoints once.

---

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

[devin-ai-integration]

Good flag. I smoke-tested /topic (HTTP 200) on both the Maven and Gradle jars. The other mappings resolve by pattern specificity as you note, and TopicService.getTopicWithId throwing NoSuchElementException for unknown ids is pre-existing behaviour unchanged by this upgrade. No circular-reference beans exist here (plain @RestControllers), so the 2.6+ default rejection doesn't apply. I've offered the requester an end-to-end run via the testing agent to exercise the add/update/delete endpoints beyond /topic.

[devin-ai-integration]

📝 Info: Both java.version and maven.compiler.release are set

spring-boot-starter-parent already derives maven.compiler.source/target from java.version; adding maven.compiler.release=17 is redundant (maven-compiler-plugin gives release precedence). Harmless, but the two properties can drift if someone edits only one of them later.

---

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

[devin-ai-integration]

Intentional — the task brief explicitly asked for both <java.version>17</java.version> and <maven.compiler.release>17</maven.compiler.release>. release takes precedence and pins to 17, which is the safer of the two if they ever drift. Keeping as-is to match the requested spec.