https://kotlinlang.org logo
Title
o

Olaf Gottschalk

04/20/2023, 3:31 PM
Hey scripting enthusiasts! I have a new problem since I upgraded my product which includes the Kotlin script compiler to Kotlin 1.8.20... very annoying and I cannot really see what has changed besides the version number of Kotlin. It has worked as-is for several Kotlin versions and now breaks. Inside my code I receive `String`s which contain code that needs to be compiled on the fly. The compile method takes the code snippet and calls
eval
on the script engine. After the update to Kotlin 1.8.20 when my scripts contain
String
operations such as
val x = "Hello"
x.uppercase()
I get this horrible exception:
error: cannot access '<http://java.io|java.io>.Serializable' which is a supertype of 'kotlin.String'. Check your module classpath for missing or conflicting dependencies
The point is: I did not change anything there. I am using good old JVM 11 (due to some 3rd party libs that are very slow to upgrade, thanks go out to to SAP and IBM) Looking at the Gradle dependency tree reveals nothing out of the ordinary, every Kotlin dependency is at 1.8.20. I do not see any conflicts there. And of course, my static code compiles just fine, it is just the dynamic code compiled at runtime that now complains. Does anybody have any hints for me on how to check & proceed? THANKS!
i

ilya.chernikov

04/24/2023, 10:08 AM
Hi @Olaf Gottschalk It looks like a bug to me. I've seen a couple of this sort recently, but I cannot figure out which might be your case. Please file an YT issue, preferably with some additional info. The stacktrace may help, as well as some code or description how you're compiling/executing your script. As a workaround, I can only suggest to rollback to 1.8.10 for now.
o

Olaf Gottschalk

04/24/2023, 10:40 AM
The toughest thing here is that my script compiling function lives in a separate lib which is reused in many of our projects. All of them Gradle Projects, all of them targeting Java 11. In the project itself, a unit test compiling this script snippet works fine, but in an external project depending on our lib it breaks. This is so weird as I have been using Kotlin 1.6.x up to 1.8.10, always just bumping up the version number and everything worked, and now it doesn't anymore. How to set up a small project showcasing this is going to be very hard. Do you have a tip on how to "see" what the compiler sees as the dependencies at the time of compilation?
i

ilya.chernikov

04/24/2023, 11:06 AM
There is no need to setup a repro project, at least not now. I understand more or less what's going on - somewhere in the compilation path the
java.home
system properties is not processed properly. I just need to understand which path is missing the action. So if you'll show me the relevant part of the stacktrace and/or the code that set up script compilation, I might already be able to guess the reason and maybe offer a workaround.
There is no way to see what script compiler uses as a compilation classpath, only debugging.
If you want to try to fight it on your own, you can try also to add the JDK classpath to the regular scripting classpath manually.
o

Olaf Gottschalk

04/24/2023, 11:30 AM
How would I denote the JDK classpath in terms of syntax? Is it just one lib name? Like kotlin-stdlib for the Kotlin lib?
My biggest problem so far was that modifying the scripting classpath requires different settings depending on whether I run unit tests vs a production setup in docker vs fat jar vs a start within ImtelliJ. It's somewhat cumbersome to differentiate between all of these cases.
i

ilya.chernikov

04/24/2023, 2:52 PM
I realized that you probably won't be able to get a modular (9+) SDK into classpath. You'll need to pass the
-jdk-home
to the compiler instead. But how to do it, depends on how you're launching scripts.
o

Olaf Gottschalk

04/24/2023, 3:05 PM
I am not launching them. I use them to internally return a dynamic transformation function which is used to manipulate data.
i

ilya.chernikov

04/24/2023, 3:16 PM
But what API are using for it?
o

Olaf Gottschalk

04/24/2023, 3:27 PM
You mean JDK? Plain old 11.
i

ilya.chernikov

04/25/2023, 6:37 AM
No, I mean scripting API. Are you using JSR-223 or
BasicJvmScriptingHost
or maybe something else?
o

Olaf Gottschalk

04/25/2023, 2:39 PM
I'm using JSR-223
i

ilya.chernikov

04/26/2023, 2:41 PM
I made a few more attempts to guess your configuration and reproduce something similar. I failed so far. It could be much easier if you would provide me with some details, I mentioned earlier. But I can give you another blind advice that might help. If you're using plain default
kotlin-scripting-jsr223
jar, you may try to set experimental
kotlin.jsr223.experimental.resolve.dependencies.from.context.classloader
system property to "true", before requesting an engine. It changes the way how the context dependencies are processed in the engine, and it may help.
o

Olaf Gottschalk

04/26/2023, 3:21 PM
I will, @ilya.chernikov as soon as I am back at my computer - next week. 😔 Thanks again already! As it popped up with the version upgrade it must be related to some thing that changed in Kotlin 1.8.20. I know that's very vague! 🤣🙈
i

ilya.chernikov

04/27/2023, 10:07 AM
I know what's changed, but I assumed I fixed all the affected code paths. And so far I cannot find the one triggered in your case.
o

Olaf Gottschalk

04/27/2023, 10:08 AM
We'll find the path, I'll try to help as much as I can! If only I wasn't on holiday right now... 😉
For all of you who might be interested in this issue, here's what @ilya.chernikov and I found as the culprit of my problems: My project was started quite a long time ago, and since then, I was depending on an obsolete, old JSR223 engine factory that came with
kotlin-script-util
jar. In order to register this per config, I had a
META-INF/services/javax.script.ScriptEngineFactory
file which references this engine factory. Up until Kotlin 1.8.10 this obsolete engine factory still worked properly, so I in fact never noticed (nor knew) anything about it. Since Kotlin 1.8.20 it should NOT be used anymore. The new implementation is automatically registered when depending on
kotlin-scripting-compiler-embeddable
and
kotlin-scripting-jsr233
. So, removing the obsolete dependency and removing the
META-INF
file solved my issue! Thanks again, Ilya!
i

ilya.chernikov

05/02/2023, 3:34 PM
In fact the usages of the
kotlin-script-util
should have been replaced with other APIs and jars quite long ago, but in 1.8.20 we accidentally broke it, and since it is long obsolete - have no intention to fix. We will remove it from publishing instead in one of the next versions.