Move it to build-common where it's still used in incremental compilation
caches, and simplify a bit. In the future, it'll make sense to remove it
completely and to avoid writing it to caches. In this commit, I don't do
that to prevent the IC cache version to be updated, causing rebuilds for
all JPS projects.
#KT-41758
The main reason for this change is that the current API for class
version requirements (`KmClass.versionRequirements`) makes it impossible
to support pre-1.4 metadata where this was stored incorrectly for nested
classes: with the "version requirement table" in the outer class, and
indexes into that table in nested classes. See KT-41011.
Other than this aspect, metadata of classes is basically the same in
pre-1.4 and 1.4, which means that if some kotlinx-metadata-jvm users
really need to serialize metadata of an earlier version and they don't
care about the version requirements issue, they can just use these new
bytes but write the earlier version (e.g. 1.1) to the class file.
Everything will work the same, except for the possible version
requirements issue mentioned above.
Note that metadata version 1.4 is still supported for
`KotlinModuleMetadata.Writer` though.
#KT-41011 Fixed
kotlinx-metadata-klib can't have jvmTarget 1.6 because it embeds module
:compiler:serialization which is compiled with jvmTarget 1.8. It is
enforced by configuration error in Gradle 6.5
Instead of generating these annotation classes as package-private on
JVM, serialize their metadata to the .kotlin_module file, and load it
when compiling dependent multiplatform modules.
The problem with generating them as package-private was that
kotlin-stdlib for JVM would end up declaring symbols from other
platforms, which would include some annotations from package
kotlin.native. But using that package is discouraged by some tools
because it has a Java keyword in its name. In particular, jlink refused
to work with such artifact altogether (KT-21266).
#KT-38652 Fixed
It turns out that `jvmTarget` and `javaHome` settings in
build.gradle.kts were changing the module settings and affected the
compilation of kotlinx-metadata-jvm sources. The correct way to use JDK
8 in tests would be to change JVM target / JDK home of the specific
KotlinCompile task via its `kotlinOptions`, but JarContentTest doesn't
need JDK 8 anyway at this moment, so simplify that instead.
* To be able to deserialize metadata we need to include ":core:deserialization".
* Use per-fragment string tables.
* Read file names from strings instead of file names list.
`kotlinx-metadata-klib` is an extension of `kotlinx-metadata` that can be used to read and write metadata that is stored inside KLIBs.
Note: current version is in its early days and in active development. Almost nothing is stable or properly tested.
- remove the requirement to use Bintray repo; kotlinx-metadata-jvm is
published to Maven Central now
- remove the note about kotlin.Metadata being internal; it's public
since 1.3
Since the only use case of KmExtensionType in user code is checking if
it equals some other KmExtensionType instance, we'd like to hide as much
of its implementation details as possible, in case we want to change it
in the future
Alexander Udalov