What is the proper way to repackage/shade Kotlin dependencies


#1

I wonder if Kotlin can be used to create “zero-dependency” library for Java consumers (e.g. JDBC driver).

Of course I can just use maven-shade-plugin (or alternative) to repackage kotlin.* classes, however I wonder if https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-metadata/index.html requires some special treatment.


#2

The question is a good one, and I am curious too, but this is a bad example as the practice of shading the Kotlin runtime for a library like this leads to unnecessary duplication since it’s a runtime that may often be shared by end user code anyways. If there were backwards compat problems w/ Kotlin runtime or you had to have a single-JAR-but-scared-of-classpath situation it might be different, but in general I would avoid it.

I wonder this too. From my naive reading of the link you have, the metadata lib mutation readme, and the metadata protobuf they embed I would guess there is some non-trivial work to refactor and change the compiled package name. Things get even more complicated w/ JvmPackageName attributes and what not.

I’d say if you don’t end up getting a satisfactory answer, do some tests and make sure some of those test cases exercise Kotlin-only reflection too (e.g. KClass.qualifiedName). I would guess that, unless you use Kotlin reflection specifically (i.e. no reflection or Java-only reflection is fine), you could probably use maven-shade, shadow, or whatever. Worst case scenario, you may end up doing source-level refactorings which sounds like a nightmare.


#3
  1. JDBC drivers are often used in public static void main environment, especially when developers use no dependency management
  2. You can’t predict the environment, so end-user might use various runtime versions. This will cause conflicts