Because `public JvmTypeExtensionVisitor` was removed, a new place for `const val PLATFORM_TYPE_ID`
is required. It is logical to place it as a some kind of constant for Km node;
however, because it is platform-specific, there is a need for an empty
`KmFlexibleTypeUpperBound.Companion` in metadata common sources
and `public val KmFlexibleTypeUpperBound.Companion.PLATFORM_TYPE_ID`
extension in kotlin-metadata-jvm sources.
See also: KT-63156
This includes APIs such as:
- Visitors API
- Obsolete KotlinClassMetadata reading and writing API
- Extension and extension visitors API
- Flags and `class Flag` (a reduced version of it was moved to test sources)
- Various utility methods
Extensions mechanism got reworked with the removal of public visitors; it is
completely internal now with special accessors in kotlinx.metadata.internal
package.
Since `var KmClass.flags` is internal now (instead of being deprecated), special
utility functions with the name `_flagAccess` were added to internal package
for testing purposes.
^KT-63156 Fixed
Change package, artifact group, artifact name, and Gradle module name to
kotlin-metadata and kotlin-metadata-jvm, respectively.
In Kotlin 2.0, kotlin-metadata-jvm library is promoted to stable, and is
a part of Kotlin distribution now.
Note that kotlinx-metadata-klib is left with org.jetbrains.kotlinx group, artifact name and package
because -klib part is considered not stable and for internal use. Since it is still published via Sonatype,
it should have kotlinx group. Therefore, it will have both classes from kotlin.metadata and kotlinx.metadata packages. This is not a problem, because we already had kotlinx.metadata split package between -jvm and -klib before.
#KT-63219 Fixed
Leonid Startsev