Skip to content
This repository has been archived by the owner on Mar 11, 2022. It is now read-only.

Improvement: Reduce usage of Reflection and Bytebuddy dependency #6

Open
sleipnir opened this issue Mar 10, 2020 · 0 comments
Open
Assignees
Labels
enhancement New feature or request

Comments

@sleipnir
Copy link

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant