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


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:

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 {
    maven { url "" }

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.


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):
CopyDynamic (gradle):


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!


Yep it still happens even with shading disabled (the copydynamic project linked also doesn’t use shading). Filed here:


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


kotlinx-metadata-jvm 0.0.4 has been published.

What’s new:

  • KT-25920 Compile kotlinx-metadata-jvm with JVM target bytecode version 1.6 instead of 1.8
  • KT-25223 Add JvmFunctionExtensionVisitor.visitEnd
  • KT-26188 Do not pass field signature for accessor-only properties


Thanks for all this great work!
I was wondering why is this not published in mavenCentral as I’m using this in a kapt processor and each client that use the processor it force those to add them the maven repository:
maven { url “” }

This is really annoying as I have to leave as requirement for all libs that use this processor to add this other repository. Any idea how to overtake this?


@juanucc Thanks for the feedback. There’s no real reason why we aren’t publishing to Maven Central. I’ve created an issue:


kotlinx-metadata-jvm 0.0.5 has been published.

What’s new:

  • KT-25371 Support unsigned integers in kotlinx-metadata-jvm
  • KT-28682 Wrong character replacement in ClassName.jvmInternalName of kotlinx-metadata-jvm