There are two reasons for this. First, this class will be used in the
metadata reading library which should not have dependencies on lots of
compiler stuff JavaToKotlinClassMap depends on.
Second, it was easy to accidentally break the deserialization in old
compilers by adding another mapping to JavaToKotlinClassMap. This was
possible because ClassMapperLite is used to decide whether or not the
JVM signature is "trivial" and should be written to the metadata (at
JvmSerializerExtension.SignatureSerializer.requiresSignature). If the
signature is trivial but mentions a type added in JavaToKotlinClassMap
in the new compiler, the old compiler will not be able to load the
signature correctly. See the comment on ClassMapperLite for more
information
Alexander Udalov
a5a69c5099