Previously to use reflection on them, you had to wrap an already created object
with a "Reflection.function" or "Reflection.propertyN" call, which the JVM
back-end was doing. This was not optimal in several senses and current solution
fixes that
This appeared after introduction of KProperty in delegated property convention
methods. If a KProperty1 instance is created while constructing a KClassImpl
instance before assigning the 'jClass' field, an NPE is thrown because the
constructor of that KProperty1 instance tries to lookup the declaring class of
the property, which in some case happens to be the exact KClassImpl we're
constructing. No test added because I was not able to reproduce the behavior in
an isolated environment
Together with almost every type now there's also an id which references a type
from a separate table. Storing such ids instead of Type messages will allow to
reduce the size of the metadata for files where types are used many times over
and over again. Currently only deserialization of such types is supported,
along with the former mechanism
Inherit KProperty from PropertyMetadata, cache corresponding KProperty objects
instead of PropertyMetadataImpl objects, add support for properties with 2
receivers
When the trivial type mapping (implemented in JvmProtoBufUtil) from
ProtoBuf.Type instances works fine, don't write the signature since it can be
loaded by exactly the same trivial type mapping
This format of the string table allows to reduce the size of the Kotlin
metadata in JVM class files by reusing constants already present in the
constant pool. Currently the string table produced by JvmStringTable is not
fully optimized in serialization (in particular, the 'substring' operation
which will be used to extract type names out of generic signature, is not used
at all), but the format and its complete support in the deserialization
(JvmNameResolver) allows future improvement without changing the binary version
Store the whole method & field descriptor strings. Moving these strings to
separate annotation arguments later will allow to reuse them with the ones in
the constant pool, presumably allowing to save lots of space (up to 10%)
Alexander Udalov