Align Kotlin jvmTarget with the Java version during UpgradeJavaVersion#1120
Open
MBoegers wants to merge 2 commits into
Open
Align Kotlin jvmTarget with the Java version during UpgradeJavaVersion#1120MBoegers wants to merge 2 commits into
MBoegers wants to merge 2 commits into
Conversation
When UpgradeJavaVersion bumps a project's Java version, the Kotlin compiler keeps emitting bytecode at the older jvmTarget, leaving Kotlin classes at a mismatched bytecode level. UpgradeJavaVersion now also runs a new UpgradeKotlinJvmTargetVersion recipe that raises the Kotlin jvmTarget to match the requested Java version across: - kotlin-maven-plugin <jvmTarget> configuration - Gradle Groovy and Kotlin DSL kotlinOptions/compilerOptions blocks (string and JvmTarget.JVM_X forms, including the jvmTarget.set(...) provider) It never downgrades, and is a no-op for non-Kotlin projects. This flows through the existing UpgradeBuildToJava*ForKotlin recipes, which delegate to UpgradeJavaVersion. Discovered while testing the Spring Boot 4 migration for Kotlin. See moderneinc/customer-requests#2439
A string jvmTarget value is only valid in the legacy kotlinOptions DSL; in compilerOptions jvmTarget is a Property<JvmTarget>, so a String assignment does not compile. UpgradeKotlinJvmTargetVersion now distinguishes the enclosing block: it bumps a string literal only inside kotlinOptions, and inside compilerOptions acts only on the JvmTarget.JVM_X enum and jvmTarget.set(...) provider forms. A stray string inside compilerOptions (already non-compiling input) is left untouched for UseJvmTargetProviderSyntax to convert.
Contributor
Author
|
Looks like it overlaps |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
UpgradeKotlinJvmTargetVersionand run it fromUpgradeJavaVersionjvmTargetto match the requested Java version (Maven + Gradle)Problem
When
UpgradeJavaVersionraises a project's Java version, the Kotlin compiler keeps emitting bytecode at the oldjvmTarget, leaving Kotlin classes at a mismatched bytecode level.Solution
A new
UpgradeKotlinJvmTargetVersion(version)recipe, added toUpgradeJavaVersion's recipe list, raises the KotlinjvmTargetto match across:kotlin-maven-plugin<jvmTarget>configurationkotlinOptions/compilerOptionsblocks (string andJvmTarget.JVM_Xforms, including thejvmTarget.set(...)provider)This flows automatically through the existing
UpgradeBuildToJava*ForKotlinrecipes. Addsrewrite-kotlinas an implementation dependency (needed to parsebuild.gradle.kts).Test plan
New tests: Maven, Gradle Groovy, Gradle Kotlin DSL, do-not-downgrade, non-Kotlin no-ops, outside-block negatives
UpgradeJavaVersionTestregression passesFull CI build (local full-suite run blocked by an unrelated Java-parser environment issue)
See moderneinc/customer-requests#2439