Is there a high level overview of what's in `@Meta...

# compiler

[mbonnin]

Is there a high level overview of what's in @Metadata , *.kotlin_modules , *.kotlin_metadata , *.kotlin_builtins , what's safe to strip and what am I exposing myself to if I strip too much?

[Zac Sweers]

@Metadata contains a few things about the kotlin class (namely the kotlin version, metadata version, and a protobuf of metadata itself containing information about the kotlin language features. Only used by the compiler or kotlin-reflect (or kotlinx-metadata)

.kotlin_modules is related to this, but contain data specific to an entire module rather than specific classes. https://github.com/JetBrains/kotlin/blob/master/libraries/kotlinx-metadata/jvm/ReadMe.md#module-metadata

.kotlin_builtins I believe is a protobuf of kotlin intrinsics like Any that kotlin-reflect uses at runtime to load types

.kotlin_metadata is similar to builtins but for metadata and I believe only used by kotlin-reflect or the compiler. I don’t know exactly what’s in these files though that’s different from what’s in @Metadata annotations

[mbonnin]

Thanks! My use case is a gradle plugin that doesn't use kotlin-reflect but needs to be compiled against (from kts scripts). Looks like I can safely strip .kotlin_builtins and .kotlin_metadata . Stripping .kotlin_modules breaks top level function and stripping @Metadata breaks a few other things that I unfortunately can't remember anymore.

[Zac Sweers]

you might be fine but gradle uses kotlin-reflect anyway so I wouldn’t necessarily strive to avoid using it

[Zac Sweers]

we keep all of them for instrumentation tests in android where we use kotlin-reflect in some tests. One caveat is in a modularized project you might need to add logic to ensure module names are unique to avoid this https://discuss.kotlinlang.org/t/dealing-with-kotlin-module-conflict-when-building-apk-for-project-with-non-unique-project-names/11247

[mbonnin]

The thing is I'm trying to shade a plugin. Looks R8 relocates dependencies classes but not the corresponding .kotlin_* files so I'm not sure Gradle/the Kotlin compiler can look them up.

[mbonnin]

Not the end of the world to keep everything I guess. Was just trying to get a better feeling of what I'm breaking.

[mbonnin]

we keep all of them for instrumentation tests in android

Does that mean they end up in the production APK too? Users shouldn't need to download all theses bytes?

[Zac Sweers]

the gradle shadow plugin doesn't handle these well. There was a PR awhile back to replace its minifying logic with R8 but the maintainer never acknowledged it

[Zac Sweers]

We only use them in instrumentation tests and exclude them in production APKs

[mbonnin]

I'm trying to relocate with R8 at the moment because of these shadow relocation limitations (mainly this one). Feels like R8 gives more control but it doesn't look like it relocates the .kotlin_ either. Maybe it's ok though since it's not in the public API so Gradle should not try to do anything with the relocated classes.

[Zac Sweers]

try with 3.x, relocating metadata was only recently added