gradle reboot -- 2025W10 update

Julien Plissonneau Duquène <[email protected]> Fri, 07 Mar 2025 18:39:58 +0100
Newsgroups gmane.linux.debian.devel.java
Message-ID <[email protected]>
Good evening,

The FrankenKotlin experiment is now over, and it failed.

Le 2025-02-28 20:20, Julien Plissonneau Duquène a écrit :
> incorrectly generated code in Kotlin plugins

This wasn't as bad as it looked like actually: it was caused by the 
Kotlin compiler using the default JDK (21) as its target for API 
compatibility, so while the bytecode was compatible with Java 8 it used 
some API calls that were introduced in later JDKs instead of 
reimplementing them as inline code. Using the JDK 11 again solved that 
for the purpose of using that compiler for building Gradle.

After fixing a few more little things the next roadblock was a missing 
implicit class declaration for the script that caused the 
pluginManagement block (a function call actually) to fail to compile 
with an internal assertion error:

> * Exception is:
> java.lang.AssertionError: Undefined parameter referenced: class 
> Settings::this
> owner=class Settings_gradle; [class Settings_gradle::this]
> 
>         at 
> org.jetbrains.kotlin.ir.util.SymbolTable.referenceValueParameter(SymbolTable.kt:420)
>         at 
> org.jetbrains.kotlin.psi2ir.generators.ArgumentsGenerationUtilsKt$generateReceiver$$inlined$generateDelegatedValue$1$1.invoke(OnceExpressionValue.kt:63)
>         at 
> org.jetbrains.kotlin.psi2ir.generators.ArgumentsGenerationUtilsKt$generateReceiver$$inlined$generateDelegatedValue$1$1.invoke(OnceExpressionValue.kt:32)
>         at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:74)

It seemed like not much would be needed to fix this, but this was 
actually a rabbit hole. My cherry-picks started to touch IR code, then 
backends code, then plugins code, and I ended up facing walls of build 
errors after applying each of them, and fixing these errors required new 
picks, which meant going back to new walls of errors on modules I just 
barely got to build. After picking 19 commits and adding 9k lines of 
patches I estimated that I wasn't even half done fixing that single 
issue and decided that it was definitely not worth continuing.

I computed a few stats to illustrate how this Kotlin project was a 
moving target (and probably still is) by then. Between v1.3.31 
(2019-04-25) and v1.3.70 (2020-03-03), that's an interval of a bit more 
than 10 months, there were 1114 commits that affected some source files 
under compiler/ir alone (more than 3 commits/calendar day on average), 
for 571k lines of git log -p and 204k lines of git diff. Overall there 
were 8236 commits for 4.4M lines of git log -p between the same 
releases. For comparison over the same period that's a bit more than 10% 
of the activity of the Linux kernel tree in number of commits, and about 
44% in number of git log -p lines.

This outcome is a bit frustrating but it was the most likely one, and I 
learned a few valuable things in the process.

My plan is now to update the Kotlin package to 2.0.21 (renaming it 
kotlin2.0) and use it to build Gradle 8. I'm not sure that both package 
(and dependencies) will be in a releasable shape in time for Trixie, but 
if they miss the deadline they can still be made available later through 
backports.

Cheers,