Skip to content

Upgrade to Kotlin 2.1.10 #44497

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

dmitrysulman
Copy link
Contributor

@dmitrysulman dmitrysulman commented Feb 28, 2025

Upgrade to Kotlin 2.1.10:

See gh-38539

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Feb 28, 2025
@wilkinsona
Copy link
Member

wilkinsona commented Feb 28, 2025

Thanks for the PR. Unfortunately, moving the examples to a kotlin subpackage will cause problems with docs. Instead, we prefer this build.gradle approach:

// To avoid a redeclaration error with Kotlin compiler
tasks.named('compileKotlin', KotlinCompilationTask.class) {
    javaSources.from = []
}

It hides the Java sources from Kotlin compilation.

@wilkinsona wilkinsona added the status: waiting-for-feedback We need additional information before we can continue label Feb 28, 2025
@dmitrysulman
Copy link
Contributor Author

@wilkinsona thanks for the feedback.

Unfortunately, moving the examples to a kotlin subpackage will cause problems with docs.

Yes, I wasn't sure about this approach. I changed include-kotlin property value in the antora-asciidoc-attributes.properties:

include-kotlin= ROOT:example$kotlin/org/springframework/boot/docs/kotlin

and was able to build the docs locally without a problem.

Anyway I'll fix the PR according to your suggestion.

@spring-projects-issues spring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue labels Feb 28, 2025
@dmitrysulman dmitrysulman force-pushed the kotlin-2.1.10-migration branch from 1d9bbc4 to d757a21 Compare March 1, 2025 09:01
@@ -304,6 +306,26 @@ task runLoggingFormatExample(type: org.springframework.boot.build.docs.Applicati
normalizeTomcatPort()
}

// To avoid a redeclaration error with Kotlin compiler
tasks.withType(KotlinCompile) {
javaSources.from = [
Copy link
Contributor Author

@dmitrysulman dmitrysulman Mar 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are the Java classes that are used by some of the Kotlin examples. We have 14 such classes.

Another approach is to completely decouple the Java and Kotlin examples and add a Kotlin replacement for each of the below classes. But this must be done carefully since some of these classes are used directly in the include-code block of the docs, and having a Kotlin version under the same package is unwanted. To prevent Asciidoctor from picking them up, we need to place them in a package with a name that differs from the Java version.

@snicoll
Copy link
Member

snicoll commented Mar 2, 2025

For the record we’ve already done the work of upgrading to Kotlin2. I’d rather us taking this forward and then review whatever needs to be.

See 4c6b493

@dmitrysulman
Copy link
Contributor Author

@snicoll thanks for the information, didn't know about this. I'll be happy with any decision made by the Spring Boot team.

Let me add a couple of comments to the referenced commit.

As of Kotlin 2, it is now longer possible to have a Java type and a
Kotlin type with the same name. As our code samples follow that
unfortunate pattern, this commit makes sure that the Kotlin sample code
does not depend on any of the Java counterpart and configure the kotlin
compilation plugin to ignore Java sources.

As I mentioned earlier some of these Java code samples are used directly in the include-code block of the docs. For example Nested class is used here:
Screenshot 2025-03-02 at 14 44 17
Now in the Kotlin tab of this code block we will have an empty Nested class which is undesirable. A possible solution is to place such classes in a different package to prevent them from being picked up by Asciidoctor.

The minimum version of Gradle is 7.6.4. It bundles a version of Kotlin that
cannot compile a Kotlin build script when spring-core, compiled with Kotlin
2.1, is on the classpath. Using Gradle 8.12 to run the DSL tests avoids
the problem.

It’s still possible to compile Kotlin DSL build scripts using Gradle 7.6.4, even when Spring itself is compiled with Kotlin 2.0+. The issue arises due to the presence of multiple Kotlin JARs compiled with Kotlin 2.0+ on the build script classpath, specifically kotlin-build-tools-api and kotlin-native-utils. To resolve the issue, these JARs should be excluded from the build script classpath for Gradle versions that embed a Kotlin version prior to 2.0.

- Upgrade kotlinVersion to 2.1.10
- Remove org.jetbrains.kotlin:kotlin-compiler-embeddable from dependencies
- Replace deprecated kotlinOptions with compilerOptions
- Update KotlinConventions of ConventionsPlugin to set Kotlin apiVersion
  and languageVersion to 2.1
- Fix redeclaration error with Kotlin compiler on spring-boot-doc
- Upgrade PluginClasspathGradleBuild to inject missed Kotlin compiler
  related jars

See spring-projectsgh-38539

Signed-off-by: Dmitry Sulman <[email protected]>
@wilkinsona
Copy link
Member

@dmitrysulman please don't use 4.0.x as a base branch at this time. It's only intended for collaboration among the core team at this time and it's likely that it won't be in a position to accept external contributions for several weeks if not months.

@dmitrysulman
Copy link
Contributor Author

@wilkinsona I see, thanks.

@dmitrysulman
Copy link
Contributor Author

Closing this PR since it's not relevant.

@wilkinsona wilkinsona removed status: waiting-for-triage An issue we've not yet triaged status: feedback-provided Feedback has been provided labels Mar 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants