Just putting it out there in case anyone else is s...

# gradle

[darkmoon_uk]

Just putting it out there in case anyone else is seeing this:
Taking my project from Kotlin 1.6.10 to 1.6.20 causes this StackOverflowError when Gradle syncing the project.

Same result on Gradle 7.4.2 and 7.4.1

Stack Overflow Error on Kotlin Upgrade.txt

[darkmoon_uk]

Found no other references online, but suggests there's a Kotlin 1.6.20 issue 🤷

[tapchicoma]

what type of project do you have?

[tapchicoma]

and does it fail only on IDEA sync or on the building via Gradle cmd?

[tapchicoma]

@darkmoon_uk could you create a Kotlin issue with repro project, so we could fix it in 1.6.21 release?

[darkmoon_uk]

Ok, it's been a busy couple of days but I'll try to get some answers on it tonight.

[darkmoon_uk]

In my project, the issue is somehow related to using withJava() on a JVM multi-platform module.

[darkmoon_uk]

Just recreating a new KMP project using with withJava() didn't reproduce it.

[darkmoon_uk]

Going to attach a debugger to Gradle during sync to try and learn more...

[tapchicoma]

If you will fail to find the reason, possibly copy just Gradle setup in your project using project-replicator and open new KT issue

[darkmoon_uk]

Thanks, I didn't know about this tool, I'll use it to extract the structure.

What I learned so far is...
The stack overflow begins at:
org.gradle.api.tasks.bundling.AbstractArchiveTask#getArchivePath
It then loops around these methods (in reverse order, as excerpted from stack trace)

calculateValue:103, AbstractMinimalProvider (org.gradle.api.internal.provider)
calculateOwnValue:49, AbstractCombiningProvider (org.gradle.api.internal.provider)
calculateValue:103, AbstractMinimalProvider (org.gradle.api.internal.provider)
calculateValueFrom:128, DefaultProperty (org.gradle.api.internal.provider)
calculateValueFrom:26, DefaultProperty (org.gradle.api.internal.provider)
doCalculateValue:133, AbstractProperty (org.gradle.api.internal.provider)
calculateOwnValue:127, AbstractProperty (org.gradle.api.internal.provider)

I note that these are all within Gradle, but it does not occur on the same version of Gradle when Kotlin 1.6.10 and associated multi-platform plugin are used.
So, perhaps the Multiplatform plugin has changed the way it presents a Jar-name property to Gradle when withJava() is enabled?

[darkmoon_uk]

When stepping through, I see that the 'touch point' between Gradle and Kotlin Multiplatform plugin occurs at:
transform:132, KotlinJvmTarget$disableJavaPluginTasks$1$2 (org.jetbrains.kotlin.gradle.targets.jvm)

[darkmoon_uk]

There was a change here in KotlinJvmTarget.kt , 1.6.10 on left, 1.6.21 on right.

[tapchicoma]

archiveFile was deprecated and this was a fix for https://issuetracker.google.com/issues/193558867

[tapchicoma]

anyway please open an issue with repro project 👏

[darkmoon_uk]

I'll try project replicator now; but a little doubtful as some of my project configuration is done by composite plugin.

[darkmoon_uk]

Which may complicate matters.

[darkmoon_uk]

I'll try nonetheless.

[darkmoon_uk]

@tapchicoma FYI I reproduced it without using replicator, in single Gradle file 🎉

[darkmoon_uk]

It's caused by setting the multiplatform Jar output name to be the same as the Java Jar output name, which is important for my use-case (making the output Jar still work with CliKt start script).

[darkmoon_uk]

I'll raise the ticket.

[darkmoon_uk]

Narrowed it down more, I think there's an unintended(?) change to the Java Jar name provider in 1.6.2x using `withJava()`:

In 1.6.10 if I query the name of the archive from these tasks I get:
Jar = `StackOverflowRepro-1.0-SNAPSHOT.jar`✅
JvmJar = `StackOverflowRepro-jvm-1.0-SNAPSHOT.jar`✅

In 1.6.2x if I query the name of the archive from these tasks I get:
Jar = `StackOverflowRepro-jvm-1.0-SNAPSHOT.jar`🚫 (Shouldn't contain jvm )
JvmJar = `StackOverflowRepro-jvm-1.0-SNAPSHOT.jar`✅

...the Jar and JvmJar tasks now have the same name provider. In my project I need the Multiplatform plugin to output the name that the Java plugin would have given. So to do this robustly I assigned it the Java plugin's name provider. But now that JvmJar task has the same name provider as the Jar task, I'm now effectively assigning the provider to itself which caused the StackOverflowError ! 😱

[darkmoon_uk]

I think that 1.6.2x should still retain the Java Jar plugin's name provider for the Jar task.

[darkmoon_uk]

I will put this in the ticket.

[darkmoon_uk]

Second thoughts; that change actually fixes the whole reason why I had to put that workaround in the first place 🙃

[darkmoon_uk]

...that the Jar distribution/execution scripts generated by Jar didn't get the right multiplatform Jar name.

[darkmoon_uk]

Now they do.

[darkmoon_uk]

So the fix is just to delete my workaround. Tested and it works.

[darkmoon_uk]

Well, a painful journey but good outcome.

[darkmoon_uk]

I think there's probably no need to raise a ticket now; hopefully this ☝️ leaves enough keyword breadcrumb for any poor soul who got themselves wound-up in the same situation.