Update Kotlin to 2.0.20

[Bencodes]

No description provided.

[restingbull]

Hm. The checksum is wrong?

Checksum was 831e83824c3a0bc5786d6aaf462ad29e0fc1a708e4fc314035f8444d850206d2 but wanted d0f05819c027a36a068c5ccf028dff6d2510922b22c7587ab2a544cf41cbdb4a

[Bencodes]

@restingbull thanks, updated the sha to the correct one.

[agluszak]

(15:27:15) ERROR: /workdir/examples/android/libAndroid/BUILD.bazel:17:15: KotlinCompile //libAndroid:util { kt: 1, java: 0, srcjars: 0 } for armeabi-v7a failed: (Exit 1): build failed: error executing command (from target //libAndroid:util)
  (cd /var/lib/buildkite-agent/.cache/bazel/_bazel_buildkite-agent/a90baed335bed067b1333b8416aecd77/execroot/android_example && \
  exec env - \
    LC_CTYPE=en_US.UTF-8 \
    REPOSITORY_NAME=rules_kotlin \
  bazel-out/k8-opt-exec-2B5CBBC6/bin/external/rules_kotlin/src/main/kotlin/build '--flagfile=bazel-out/android-armeabi-v7a-fastbuild/bin/libAndroid/util-kt.jar-0.params')
# Configuration: 6fdd1f90f42f28a28d36b328ac6502d8d4699741b3a8ed745c6f60617729e171
# Execution platform: @local_config_platform//:host
warning: language version 1.5 is deprecated and its support will be removed in a future version of Kotlin
exception: java.lang.LinkageError: loader constraint violation: loader org.jetbrains.kotlin.preloading.MemoryBasedClassLoader @7f13d6e wants to load interface kotlin.jvm.functions.Function2. A different interface with the same name was previously loaded by org.jetbrains.kotlin.preloading.MemoryBasedClassLoader @d44fc21. (kotlin.jvm.functions.Function2 is in unnamed module of loader org.jetbrains.kotlin.preloading.MemoryBasedClassLoader @d44fc21, parent loader 'bootstrap')

Hmm

[agluszak]

https://youtrack.jetbrains.com/issue/KT-71344/Bazel-ruleskotlin-java.lang.LinkageError-loader-constraint-violation-loader

[udalov]

I don't know the exact change which caused this to start to fail on 2.0.20 (still looking for it), but investigating the classpath that is created for the compiler in KotlinToolchain.createClassLoader, I found out that there are jars which pack (non-shadowed) kotlin-stdlib, kotlin-reflect and other libraries inside them:

• skip-code-gen.jar
• jdeps-gen.jar

(I'm running bazel build //src/test/kotlin/io/bazel/testing:testing)

Kotlin's preloader (ClassPreloadingUtils.preloadClasses) does not support, and never supported this. Preloader operates under an assumption that any class is present in exactly one of the files on the classpath.

I don't know what those jars are, but maybe the solution would be to somehow ensure that they don't repack libraries which they depend on here.

Another solution would be not to use Kotlin's preloader at all, but rather create a simple URLClassLoader instead. This could be beneficial in the future because preloader is an internal Kotlin utility which has no guarantees and thus might break in any release. However, when I try to create URLClassLoader locally, the test passes, but I get other kinds of class loading errors on other tests, which need to be investigated further.

I guess I would like to know what those jars are for, and is it possible to avoid packing kotlin-stdlib inside them? Feel free to share any other opinions or suggestions. I admit I'm not very knowledgeable in this project or Bazel ecosystem altogether, so I might be missing some trivial stuff.

[restingbull]

I don't know the exact change which caused this to start to fail on 2.0.20 (still looking for it), but investigating the classpath that is created for the compiler in KotlinToolchain.createClassLoader, I found out that there are jars which pack (non-shadowed) kotlin-stdlib, kotlin-reflect and other libraries inside them:

* `skip-code-gen.jar`

* `jdeps-gen.jar`

(I'm running bazel build //src/test/kotlin/io/bazel/testing:testing)

Kotlin's preloader (ClassPreloadingUtils.preloadClasses) does not support, and never supported this. Preloader operates under an assumption that any class is present in exactly one of the files on the classpath.

I don't know what those jars are, but maybe the solution would be to somehow ensure that they don't repack libraries which they depend on here.

That is roughly the direction I headed setting the stdlibs on the toolchain. It offers the ability to clear up correctness issues found when importing dependencies from maven (the stdlibs popup every so often.)

This didn't seem clear out the issue in local testing but it removes at least one part.

Another solution would be not to use Kotlin's preloader at all, but rather create a simple URLClassLoader instead. This could be beneficial in the future because preloader is an internal Kotlin utility which has no guarantees and thus might break in any release. However, when I try to create URLClassLoader locally, the test passes, but I get other kinds of class loading errors on other tests, which need to be investigated further.

To be honest, the kotlin preloader predates my involvement with the project, so I can't speak authoritatively about it. My assumption is that it was necessary -- and never challenged it, as I've had other issues to fix (like proper plugin support with arguments. That one is a doozy.)

I guess I would like to know what those jars are for, and is it possible to avoid packing kotlin-stdlib inside them? Feel free to share any other opinions or suggestions. I admit I'm not very knowledgeable in this project or Bazel ecosystem altogether, so I might be missing some trivial stuff.

The error seems to be triggered by the loading compiler plugins. I haven't had the time to trace it down all the way, but that is where it seems to crop up the most.