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
Previously, we compared instances of different enums and thus the
conditions were always true. This did not affect visible behavior of the
program except the fact that we've been writing default field values
(kind and level) for version requirements to protobuf where they
could've been omitted
With gradle > 5.0 `publish()` helper call should be done before
`noDefaultJar()` or any other artifact hacks, otherwise singing plugin doesn't sign any jars
Previously this files was stored in /src directory and was included in
resources mainly by SourceSet.projectDefault from sourceSets.kt:
val processResources = tasks.getByName(processResourcesTaskName) as ProcessResources
processResources.from("resources") { include("**") }
processResources.from("src") { include("META-INF/**", "**/*.properties") }
Also there are some custom rules like this:
resources.srcDir("../idea-analysis/src").apply { include("**/*.properties") }
resources.srcDirs("idea-repl/src").apply { include("META-INF/**") }
All this rules are synthesized in script
https://github.com/snrostov/kotlin-migrate-resources/blob/master/src/main/kotlin/main.kt
This commit created using that script. See README.md for more details on
script.
Preface: Kotlin 1.3 will be able to read metadata of .class files
produced by Kotlin 1.4 (see KT-25972). Also, to simplify implementation
and to improve diagnostic messages, we're going to advance JVM metadata
version to 1.4.0 in Kotlin 1.4, and would like to keep it in sync with
the compiler version thereafter. This presents a problem: in an unlikely
event that before releasing 1.4, we find out that the metadata-reading
implementation in 1.3 was incorrect, we'd like to be able to fix the bug
in that implementation and _forbid_ 1.3 from reading metadata of 1.4.
But prior to this commit the only way to do this was to advance the
metadata version, in this case to 1.5, and that breaks the
metadata/compiler version equivalence we'd like to keep.
The solution is to add another boolean flag to the class file, called
"strict metadata version semantics", which signifies that if this class
file has metadata version 1.X, then it can only be read by the compilers
of versions 1.X and greater. This flag effectively disables the smooth
migration scenario proposed in KT-25972 (as does increasing metadata
version by 2), and will be used only in hopeless situations as in the
case described above.
Otherwise this code behaves incorrectly on getter-only properties: it
returns a meaningless field signature whereas the property has no field.
It's hard to come up with an example of when this could matter in
compiler code, but it's very noticeable in kotlinx-metadata-jvm
#KT-26188 Fixed
Vyacheslav Gerasimov