Support for Kotlin 2.2.0 Projects

[goafabric]

So with Openrewrite Gradle Plugin 7.13.0 / 7.15.0 + Kotlin 2.2.0 + Java 21
with Kotlin 2.0 Projects, I am getting multiple errors like below, telling that it cannot parse these files.

So digging in a little deeper with chatgpt ... we've found out that rewrite-kotlin is using Kotlin 1.9
https://github.com/openrewrite/rewrite/blob/main/rewrite-kotlin/build.gradle.kts

And in turn, downgrading the Project to Kotlin 1.9, makes Openrewrite to work again.
Unfortunately i cannot share the file(s) in question here .. but it seems like there is an obvious connection.

More simpler Projects with less files work.
But in this Spring BATCH Project Openrewrite basically complains about all files.

So is it possible that current Openrewrite only works with Kotlin 1.9 Projects ?
And is there an Upgrade planned to Kotlin 2.2.0 ?

What is mostly used in this receipe is ChangeType like this

Changetype

- org.openrewrite.java.ChangeType: oldFullyQualifiedTypeName: org.springframework.batch.core.Step newFullyQualifiedTypeName: org.springframework.batch.core.step.Step

Error
[org.openrewrite.gradle.isolated.DefaultProjectParser] org.jetbrains.kotlin.util.FileAnalysisException: While analysing somefile.kt:12:51: org.jetbrains.kotlin.utils.exceptions.KotlinIllegalArgumentExceptionWithAttachments: Unexpected FirClassLikeSymbol null for class org.jetbrains.kotlin.fir.symbols.impl.ConeClassLikeLookupTagImpl org.jetbrains.kotlin.util.AnalysisExceptionsKt.wrapIntoFileAnalysisExceptionIfNeeded(AnalysisExceptions.kt:56) org.jetbrains.kotlin.fir.FirCliExceptionHandler.handleExceptionOnFileAnalysis(Utils.kt:171)

[timtebeek]

hi! There's two parallel efforts to potentially bring Kotlin 2.x support to OpenRewrite

• Kotlin 2 #5963
• Add support for Kotlin 2.x #5575

You'll want to monitor those PRs for any updates. Either of those should close this issue once merged. 🙏🏻

[goafabric]

Thank you

[sapreanupam]

Hey @timtebeek , do we have any rough target date for the PR.

[timtebeek]

No target date at the moment no. Especially where it concerns parsers we prefer to get things right, as others will build recipes based on the modeling choices we make here, making those hard to revise later. And then there's constantly other developments vying for attention as well.