"-Xno-kotlin-nothing-value-exception" is needed to temporarily prevent
the problem happening in the composite build with Kotlin/Native
(ClassNotFoundException from KClassImpl.Data).
"-Xno-optimized-callable-references" is added just in case of any
similar problem.
They are used only in main build's .gradle.kts files, so it is more
flexible to define them as extensions - no need to republish
kotlin-build-gradle-plugin when another such property is to be added.
The Android build pipeline can extract embedded proguard configurations
from dependencies and merge them automatically. This adds a conservative
proguard configuration to the kotlin-reflect JVM artifact in support of
that. This focuses mostly on just retaining what's necessary for
kotlin-reflect's own functionality to operate, but could be expanded if
community feedback discovers other good candidate rules.
With this in place - most Android projects using R8 or Proguard should
Just Work™️ with kotlin-reflect.
Provide additional modular artifacts as a workaround for KT-21266
Update module-info declarations:
- add new packages
- add exports and opens for internal PlatformImplementations
- remove exports of kotlin.coroutines.experimental.*
#KT-27919 Fixed
Do not pass the jars for modules such as descriptors, descriptors.jvm,
etc to `--module-path` because javac assumes that these are separate
modules (even though they're listed later as parts of this module in
`--patch-module), and prohibits to have split packages and foreign
service implementations among them
It's no longer needed for checking binary compatibility.
Clean build of these libraries is no longer required too.
Cleanup build.gradle of binary-compatibility-validator.
Use distJar configuration instead.
It's necessary because currently when using default-type, subproject
starts having a transitive dependency to :kotlin-stdlib-common
and that leads to exception from KT-20897 when building light classes
This change might be reverted once KT-23942 is fixed
#KT-23942 Submitted
The standard way of loading resources with built-ins metadata from the
current class loader no longer works in the modular mode on Java 9
because the current class loader is for module 'kotlin.reflect', but the
metadata is located in the module 'kotlin.stdlib'. On Java 9, we now use
the class loader of 'kotlin.stdlib' to load these resources.
#KT-21266 Fixed
This fixes the "Some JAR files in the classpath have the Kotlin Runtime
library bundled into them" warning when compiling all modules that
depend on kotlin-reflect-api. This warning is reported on jars in the
classpath which look like standard library artifacts, but in fact are
not because their manifest does not say so. With this change, we're now
writing the manifest of standard library artifacts to the resulting jar
of kotlin-reflect-api, with the standard library component name
"internal" (in fact, it doesn't affect anything here, any name would be
OK) to make the compiler believe that this is actually a standard
library jar
This is needed only for faster compilation of the Kotlin project itself
and has no effect on the public artifact
org.jetbrains.kotlin:kotlin-reflect.
The problem this is solving is the rebuild of the project once anything
has been changed in modules in 'core' (even inside function bodies, i.e.
a non-API change). Previously, changes in 'core' led to the compilation
of kotlin-reflect, which led to the rebuild of all modules depending on
kotlin-reflect directly or indirectly (which is almost all modules in
the project) because kotlin-reflect's artifacts are custom-built and the
changes can not be picked up incrementally. But 99.9% of the time the
initial changes in 'core' could not have any effect on the usages of
kotlin-reflect, because classes from those modules are moved to an
internal package in kotlin-reflect and thus are an internal
implementation detail.
Now, changes in 'core' still lead to the compilation of kotlin-reflect
and to the process of building the custom jar. But if a module depends
on kotlin-reflect-api, not kotlin-reflect, then the incremental
difference checker will detect that the module does not have to be
recompiled if there hasn't been any changes to the API of
kotlin-reflect-api. Which means that the module will not be rebuilt on
every change in 'core'.
This commit only introduces the new module. The dependencies
(kotlin-reflect -> kotlin-reflect-api) are replaced in the next commit.
Alexander Udalov