Has anyone had the experience of invoking K2JVMCom...
# compiler
c
Has anyone had the experience of invoking K2JVMCompiler with a plugin and getting this error:
Copy code
java.lang.NoClassDefFoundError: org/jetbrains/kotlin/compiler/plugin/CommandLineProcessor
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
	at <http://java.net|java.net>.URLClassLoader.defineClass(URLClassLoader.java:468)
	at <http://java.net|java.net>.URLClassLoader.access$100(URLClassLoader.java:74)
	at <http://java.net|java.net>.URLClassLoader$1.run(URLClassLoader.java:369)
	at <http://java.net|java.net>.URLClassLoader$1.run(URLClassLoader.java:363)
	at java.security.AccessController.doPrivileged(Native Method)
	at <http://java.net|java.net>.URLClassLoader.findClass(URLClassLoader.java:362)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at org.jetbrains.kotlin.preloading.MemoryBasedClassLoader.loadClass(MemoryBasedClassLoader.java:75)
	at org.jetbrains.kotlin.preloading.MemoryBasedClassLoader.loadClass(MemoryBasedClassLoader.java:82)
	at org.jetbrains.kotlin.preloading.MemoryBasedClassLoader.loadClass(MemoryBasedClassLoader.java:75)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
As you can see it's running in a subset class loader that was seeded with the compiler jar -- but it can't find the class that is most certainly in the jar. (double checked, in fact) Tried add the jar explicitly to the cp, as well as passing it .as a plugin (bit of a hail mary, that.) Any advice?
Never mind -- running afoul of the default methods on CommandLineProcessor when implementing the interface in java. This does, rather effectively, limit plugins to be Kotlin only. @christiangruber
c
Good to know. I guess we'll have to boostrap the compiler with kapt after all (or remove usage of annotation processing).
c
Amendment. While the java implementation of a plugin is, in fact, possible, it is quite ugly. More notable -- when attempting to invoke a plugin inside the InMemoryClassLoader, it is beneficial to load the plugin into same classloader as the Compiler. Without it, the Compiler extension interfaces can fail due to a NoClassDef error, possibly due to competing classloaders.
👍 1
z
Hey 👋 Sorry for digging such old thread but I was looking into adding support for generating Java code to
kt_ksp_plugin
(https://github.com/bazelbuild/rules_kotlin/issues/1074) and with some first attempts on it (edit: with these commit changes), I’m facing an issue where plugin is loading the same interface into the same classloader as compiler (since both, dagger and kotlin compiler, use guava..):
Copy code
exception: java.lang.LinkageError: loader constraint violation: loader 'app' wants to load interface com.google.common.base.Supplier. A different interface with the same name was previously loaded by org.jetbrains.kotlin.preloading.MemoryBasedClassLoader @1efed156. (com.google.common.base.Supplier is in unnamed module of loader org.jetbrains.kotlin.preloading.MemoryBasedClassLoader @1efed156, parent loader 'bootstrap')
I’m quite new to bazel kotlin rules so I was wondering if you would possibly have some guidance how to approach it 😓.. In this specific case it doesn’t really seem beneficial to load the plugin into same classloader as compiler (but I guess it wouldn’t be a problem with
kotlin-compiler-embeddable
💭) 😅