The main changes are in jvm_package_table.proto and ModuleMapping.kt.
With JvmPackageName, package parts can now have a JVM package name that
differs from their Kotlin name. So, in addition to the old package parts
which were stored as short names + short name of multifile facade (we
can't change this because of compatibility with old compilers), we now
store separately those package parts, which have a different JVM package
name. The format is optimized to avoid storing any package name more
than once as a string.
Another notable change is in KotlinCliJavaFileManagerImpl, where we now
load .kotlin_module files when determining whether or not a package
exists. Before this change, no PsiPackage (and thus, no JavaPackage and
eventually, no LazyJavaPackageFragment) was created unless there was at
least one file in the corresponding directory. Now we also create
packages if they are "mapped" to other JVM packages, i.e. if all package
parts in them have been annotated with JvmPackageName.
Most of the other changes are refactorings to allow internal names of
package parts/multifile classes where previously there were only short
names.
Unlike the JVM target platform, the JS back-end does
not track getters' and setters' usages separately,
so when either accessor of some property is changed,
all usages of that property will be rebuilt.
Previously ProtoCompareGenerated could
go out of bounds when comparing protos
with different number of annotations.
That happend because JsProtoBuf.parameterAnnotation
is a repeated extension, but the generated code for
comparing repeated extensions was incorrect.
JvmProtoBuf does not have repeated extensions (at least for
the class and package descriptors),
so the problem was not detected before.
There was a bunch of if-else blocks checking if new IC was enabled or not.
These blocks became useless after `IncrementalCompilation.isExperimental`
was replaced with `IncrementalCompilation.isEnabled`, because when IC is not enabled
we don't use caches anyway.
By default SmartList is used there for storing values of a multimap,
so a lot of duplicated items is stored there (file names are being
duplicated).
Even although there is a separate interner for these values,
retained memory size has been reduced for 30M when compiling `idea`
module in Kotlin project
Write the modular JDK (9+) path to the module.xml file passed to the
compiler from the JPS plugin. This path is then recorded in the compiler
configuration in KotlinToJVMBytecodeCompiler.configureSourceRoots. This
is needed because in JPS plugin, we pass "-no-jdk" and thus no JDK home
path was recorded in the compiler configuration in
K2JVMCompiler.setupJdkClasspathRoots. Presence of JDK home path in the
configuration is crucial for JDK 9 support (see
KotlinCoreEnvironment.Companion.createApplicationEnvironment), because
classes there can only be loaded with the special "jrt" file system, not
as .class files in .jar files
#KT-17801 Fixed
Ilya Chernikov