Announcing kotlinx-metadata-jvm library for reading/modifying metadata of Kotlin/JVM class files


#1

Please welcome a new library kotlinx-metadata-jvm designed for tools that need to read or modify the Kotlin metadata, such as bytecode obfuscators and annotation processors. With kotlinx-metadata-jvm, it’s possible to make sense of, and modify the data written by the Kotlin compiler in the @kotlin.Metadata annotation on the .class file, and in the .kotlin_module files.

Refer to the ReadMe for a quick introduction:
https://github.com/JetBrains/kotlin/blob/master/libraries/kotlinx-metadata/jvm/ReadMe.md

The library is published under the kotlinx project and the version number is 0.* because we’re not yet sure that the API is optimal and won’t need major refinements. Until the library is released as stable, we reserve the right to perform both source- and binary-breaking changes; however of course, we’ll do our best to minimize migration issues when these occur.

Example usage in a Gradle project:

repositories {
    mavenCentral()
    maven { url "https://kotlin.bintray.com/kotlinx/" }
}

dependencies {
    compile "org.jetbrains.kotlinx:kotlinx-metadata-jvm:0.0.2"
}

I’ll use this forum thread to notify about new versions of kotlinx-metadata-jvm and will be happy to answer any questions about the API or future goals of the library here.


#2

Hey @udalov! I’ve been trying this out in Moshi as well as a prototype for something, but in both cases I’m caught by a strange serviceloader issue where it can’t find any MetadataExtensions. They are visible in the Moshi kotlin/codegen compiler tests, but not when used in another artifact as a kapt dependency. I don’t see anything overtly wrong so not sure if I should file a bug. The crux of the issue is that it seems the only classpath available during kapt processing is the embedded compiler classpath, and I don’t see a way to manually add (or we we should need to) add any custom classpath arguments. Any thoughts?

Moshi work switching to kotlinx-metadata (maven): https://github.com/square/moshi/pull/570
CopyDynamic (gradle): https://github.com/hzsweers/copydynamic


#3

Hi @hzsweers, this looks like an artifact of using maven-shade-plugin; I’ve commented in the moshi issue. If it doesn’t work out anyway, please try disabling the relocation of kotlinx-metadata altogether and see if it works. Otherwise, please report it to our issue tracker and I’ll have a closer look. Thanks!


#4

Yep it still happens even with shading disabled (the copydynamic project linked also doesn’t use shading). Filed here: https://youtrack.jetbrains.net/issue/KT-24881


#5

kotlinx-metadata-jvm 0.0.3 has been published.

What’s new:

  • Support metadata of local delegated properties (see JvmDeclarationContainerExtensionVisitor.visitLocalDelegatedProperty)
  • KT-24881 Use correct class loader in kotlinx-metadata to load MetadataExtensions implementations
  • KT-24945 Relocate package org.jetbrains.kotlin to fix IllegalAccessError in annotation processing