After upgrading my project to Kotlin `2.0.20-Beta2...

# multiplatform

[Robert Jaros]

After upgrading my project to Kotlin 2.0.20-Beta2 I see this warning w: 'java' Gradle plugin is not compatible with 'org.jetbrains.kotlin.multiplatform' plugin. when using kotlin { jvm { withJava() } }. I'm using latest Gradle 8.9. Is this a known issue?

[Robert Jaros]

I also see this:

w: 'java' Gradle plugin is not compatible with 'org.jetbrains.kotlin.multiplatform' plugin.

Consider adding a new subproject with 'java' plugin where the KMP project is added as a dependency.

w: 'application' (also applies 'java' plugin) Gradle plugin is not compatible with 'org.jetbrains.kotlin.multiplatform' plugin.

Consider adding a new subproject with 'application' plugin where the KMP project is added as a dependency.

[chrisjenx]

that is weird. if works on older KT versions probably an incompatiblitly

[Gary Peck]

It's documented here: https://kotlinlang.org/docs/whatsnew-eap.html#deprecated-compatibility-with-gradle-java-plugins

[CLOVIS]

Wait? So this is not a bug, we are really going to need to create an additional subproject for any Java code? It's really the end of Java in multiplatform libraries?

[Robert Jaros]

It's even worse. I don't use any Java code in my project. I just want to apply some plugins for the frameworks I use with Kotlin (like Spring Boot, Micronaut or Jooby plugin).

[Gary Peck]

@CLOVIS I haven't tried it myself yet, but the docs don't say anything about withJava(), so I'm hoping that Java code in a multiplatform project is still supported. It's only the use of Java Gradle plugins in a multiplatform project that is being deprecated.

[CLOVIS]

withJava is just a shortcut to apply the Java plugin. Unless they are going to reimplement the Java plugin into the Kotlin plugin (highly doubt it), then it does mean that withJava won't be supported either.

[Robert Jaros]

In my case I develop a gradle plugin which simplifies building and packaging fullstack applications with Spring Boot. I need to setup quite complicated task dependencies and I just need spring boot plugin to be applied in the main project. Adding a plugin in a subproject is not an option (at least not without complete rework of the project). And spring boot plugin requires java plugin. I'm doomed 😭🙂

[Robert Jaros]

Can I read somewhere what are these "compatibility issues" that pushed Kotlin team to such terrible solution? 😆 Using Spring Boot with KMP is probably very common. I'm building such apps for years without problems.

[CLOVIS]

Probably something similar to why we can't have multiple targets of the same type 😕

[CLOVIS]

Personally, the main problem is it means I'm going to need to remove all Java code from KMP libraries, which means the Java code will need to be in a different artifact, so you won't be able to just import the common artifact when importing the lib from a Java project 😕

[Robert Jaros]

I think the team should reconsider increasing this warning to error. Let's leave this as a warning, even with some link to the docs. But making it an error will just break a lot of good things.

[CLOVIS]

They wouldn't start a deprecation cycle without having a plan to see it through the end. It'd be nice if we could find where this was discussed.

[Robert Jaros]

A bit here: https://youtrack.jetbrains.com/issue/KT-66542/Gradle-JVM-target-with-withJava-produces-a-deprecation-warning#focus=Comments-27-10042316.0-0

[Robert Jaros]

I feel it's android target fault and it's even worse because I've never ever written any android code at all 🙂

[Robert Jaros]

Found the issue: https://youtrack.jetbrains.com/issue/KT-69406/Deprecate-combinations-of-KMP-plugin-with-some-Gradle-Java-plugins

[Adam Semenenko]

I agree that the situation is not ideal.

In short, the reason is because Gradle is starting to prevent modification of core-plugin Configurations https://docs.gradle.org/8.7/userguide/upgrading_version_8.html#configurations_allowed_usage

The reason why KGP modified the Java Configurations here is because a KMP project (with a JVM target) needs to be consumable by a pure-Java projects.

If the KMP project also adds the java, java-library, or application (which would be better named as java-application) plugins, then a Java-only consumer won't be able to discriminate between the Kotlin/JVM artifact and the java artifact.

Currently, KGP modifies the Java Configurations so that they are disabled. But Gradle will prevent this in the future.

[Adam Semenenko]

Right now, I can only give an explanation, not a solution.

[Alexander.Likhachev]

> Wait? So this is not a bug, we are really going to need to create an additional subproject for any Java code? It’s really the end of Java in multiplatform libraries?
No. You still can use withJava without any deprecation warnings and put Java code along Kotlin code without any deprecation warnings. You just can’t apply `java`/`application` plugins within KMP plugin in the same project. We should clarify the What’s new announcement.
withJava() call applies java-base plugin which is totally fine and allows us to have control over the entities it creates

[CLOVIS]

Thanks for the information, that makes sense 😕 I wish the Gradle team would provide alternatives before starting to deprecate stuff

[Robert Jaros]

I have some doubts about this sentence: "The reason why KGP modified the Java Configurations here is because a KMP project (with a JVM target) needs to be consumable by a pure-Java projects.". Does this also apply to application projects (not libraries)?

[Adam Semenenko]

Currently KGP does not differentiate between application/library projects (unlike Java, which has java vs java-library). So yes, it applies to both, because KGP has to maintain the same behaviour.

[Robert Jaros]

Maybe it would be a good idea to change this behavior and loosen these requirements for applications only. Many popular gradle plugins which internally use java and/or application (like Spring Boot plugin, Micronaut plugin) are dedicated for applications and could still work without problems.

[chrisjenx]

So unless I missed it, we can still build a java desktop based application on kmp, as KMP handles the java source set, we just can't use things like java-library/application (which I don't think we do for KMP desktop targets anyway?

[chrisjenx]

So yeah based on the docs and templates would be good to create/suggest a template like this of those doing full app development:

-> backend (java)
common (kmp)
             -> client(kmp)

TBH I already have this (as backend started first) but would help to give a more concrete template/example

[Adam Semenenko]

> Maybe it would be a good idea to change this behavior and loosen these requirements for applications only.
Possibly... Maybe a distinct kotlin("multiplatform-application") could work... or some sort of toggle kotlin { type = Application }? But what about if someone did want to publish an application to Maven? Would it still work?

It would be nice if it just worked without any configuration! This is only a recent change, so we're still considering options, and talking with the Gradle team to try and make it nicer.

[Adam Semenenko]

Another point of concern is that if you apply java, application, and kotlin("multiplatform"), then even if KGP had some sort of 'application only' mode that worked well, there would still be tasks/Configurations/misc stuff that would not be used. E.g. compileJava - this task won't be run, Kotlin will handle compilation. These are unnecessary, will never be used, and and harm build performance.

[Robert Jaros]

I think when using a proposed workaround (creating a subproject with such plugin) the performance impact will be the same (or even worse).

[CLOVIS]

and harm build performance

how? If they are properly lazy, unused tasks are expected to be virtually free

[Adam Semenenko]

If you do notice worse performance with the workaround, please make an issue kotl.in/issue. I agree that creating a separate project isn't ideal, but that's what Gradle requires.

Just to zoom out a bit, we're focusing on the situation where applying java & KGP-multiplatform is required. In this case, maybe the performance impact isn't significant. But when we researched the projects that applied both java & KGP-multiplatform, in the majority of cases java wasn't necessary, or was only used for a single task (e.g. the Javadoc JAR)

[Adam Semenenko]

But currently when KGP-multiplatform undoes the work of java, it means objects are disabled. This is confusing to users & build script maintenance, consumes memory even if they are not run, might be accidentally run (E.g. gradle assemble could trigger a Java compilation task, even though compilation is handled by KGP), and complicate Gradle wiring (E.g. task dependencies).

[Robert Jaros]

The problem is not applying java plugin itself, but the ecosystem of plugins of many different projects, which require the java (or application) plugin.

[Robert Jaros]

This is how e.g. Spring Boot plugin works: https://docs.spring.io/spring-boot/gradle-plugin/reacting.html#reacting-to-other-plugins.java