https://kotlinlang.org logo
m

mbonnin

08/06/2021, 10:00 AM
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?
1
z

Zac Sweers

08/07/2021, 4:13 PM
@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
👌 1
🙏 1
m

mbonnin

08/07/2021, 4:18 PM
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.
z

Zac Sweers

08/07/2021, 5:05 PM
you might be fine but gradle uses kotlin-reflect anyway so I wouldn’t necessarily strive to avoid using it
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
👀 1
m

mbonnin

08/07/2021, 5:09 PM
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.
Not the end of the world to keep everything I guess. Was just trying to get a better feeling of what I'm breaking.
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?
z

Zac Sweers

08/07/2021, 5:23 PM
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
We only use them in instrumentation tests and exclude them in production APKs
👍 1
m

mbonnin

08/07/2021, 5:27 PM
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.
z

Zac Sweers

08/07/2021, 5:28 PM
try with 3.x, relocating metadata was only recently added
👍 1
👍🏼 1
18 Views