<@U0CHHN4F4> Because of fatjat (kotlin-compiler) I...
# scripting
@ilya.chernikov Because of fatjat (kotlin-compiler) I have a lot of issues with IDE when using kotlin-script-util with kotlinx.coroutines. Is it possible to stop using fat jar or at least use custom class loader as it done in spring boot?
It’s a bit abstract question. I guess you mean JSR-223 engines. It is possible to implement some custom classloading there. The script utils is in fact a thin layer on top of the some internal compiler services (+some utils in fact). But could you please elaborate, which particular issues you’re facing, and why do you think they are related to the fat jar.
Idea found two declarations: one from legal kotlinx.coroutines and another from kotlin-compiler
if kotlin-compiler instead of inlining dependency classes in fatjar(which for me looks like hack and bad practice) will inline entire jars - then this problem gone
(see screenshot with error in channel)
Agreed, fat jar is a huge issue, I wanted to use kotlin script as a web script processor for my app, but can't because its embedded dependencies and compiler's embedded dependencies conflict with libs used by the app itself, so my app currently uses groovy instead 😞
So I understand why kotlin-compiler.jar is fatjar: because users like to just
java -jar kotlin-compiler-1.2.0. jar ...
but for using kotlin-compiler.jar as dependency their dependencies should be fetched through maven/gradle.
Maybe you can produce two versions of kotlin-compiler.jar, one one version which includes
inside, and second - standard jar with dependencies. I rather like first solution, since then my application will be much smaller
There are quite many internal and external reasons for using fat jar compiler in many places, including scripting, so although we’re planning some changes there, it is unlikely that such problems will be completely resolved soon. On the other hand, isolating the compiler is not really very hard. In the simplest case switching to
moves compiler to the separate process and removes the need to have it in the classpath (you’ll need to set
property instead) If you still would like to have it in-process but in separate classloader - unfortunately there is no out-of-box solution yet, but crafting your own should’n be that difficult, I guess.
can the dependencies be shaded when including them in the far jar? that’s a common solution to avoid class conflicts.
👍 1
Nice idea, doesn't thought about it.
Exactly for that we have kotlin-compiler-embeddable. I plan to check and resolve issues with using it for the JSR223 in some nearest future.