To explain this improvement, it is necessary first to explain some of the premises of the Kotlin support library.
When I started developing this library, I intended to do all the work from scratch. This would undoubtedly be much more fun and challenging, however, after some experiments I realized that maintaining a written library from scratch that implements a new protocol and that should be in continuous and rapid evolution for a long time might not be the best choice to be made.
First, every time a feature or patch was released, it would have to be implemented in Kotlin.
Second, the protocol is not trivial and a lot of infrastructure code is needed to support it.
Since Kotlin manages to interoperate transparently with Java I found it natural to take advantage of all the work done by the Java support library and focus on delivering a fluent interface to the end user.
For this reason I recently added support for the **io.cloudstate.kotlinsupport.api.*** Package annotations for use in Cloudstate Entities. At runtime I add the necessary code at the bytecode level so that the java library can work properly and transparently. However, like any tradeoff, doing this has a cost (an additional dependency, and processing time) and therefore we must evaluate other approaches in the future.
In the case of the annotation-based API, a possible way to do this substitution would be to implement the Kotlin equivalent to the io.cloudstate.javasupport.impl.eventsourced.AnnotationBasedEventSourcedSupport and io.cloudstate.javasupport.impl.crdt.AnnotationBasedCrdtSupport classes. However, these classes execute practically all the logic of the Java library (written in Scala) and for that reason I didn't do it at that time.
In the case of a fully Kotlin API not based on Annotations, we must evaluate what the alternatives are. I don't see any at the moment.
To explain this improvement, it is necessary first to explain some of the premises of the Kotlin support library. When I started developing this library, I intended to do all the work from scratch. This would undoubtedly be much more fun and challenging, however, after some experiments I realized that maintaining a written library from scratch that implements a new protocol and that should be in continuous and rapid evolution for a long time might not be the best choice to be made. First, every time a feature or patch was released, it would have to be implemented in Kotlin. Second, the protocol is not trivial and a lot of infrastructure code is needed to support it. Since Kotlin manages to interoperate transparently with Java I found it natural to take advantage of all the work done by the Java support library and focus on delivering a fluent interface to the end user. For this reason I recently added support for the **io.cloudstate.kotlinsupport.api.*** Package annotations for use in Cloudstate Entities. At runtime I add the necessary code at the bytecode level so that the java library can work properly and transparently. However, like any tradeoff, doing this has a cost (an additional dependency, and processing time) and therefore we must evaluate other approaches in the future.
In the case of the annotation-based API, a possible way to do this substitution would be to implement the Kotlin equivalent to the io.cloudstate.javasupport.impl.eventsourced.AnnotationBasedEventSourcedSupport and io.cloudstate.javasupport.impl.crdt.AnnotationBasedCrdtSupport classes. However, these classes execute practically all the logic of the Java library (written in Scala) and for that reason I didn't do it at that time.
In the case of a fully Kotlin API not based on Annotations, we must evaluate what the alternatives are. I don't see any at the moment.
This was discussed here #4