Hello everyone! We developed a <plugin> for the Ko...

# compiler

[Anastasia Birillo [JB]]

Hello everyone! We developed a plugin for the Kotlin compiler that leverages the flows of the standard reflection approach and can find classes, objects or functions by some conditions in compile-time. The current latest version is ready and stable!

Two ways of using the plugin are supported: by limited DSL (searching of classes and objects by supertypes and annotations; and searching of functions by signature and annotations) and by extended DSL (searching of classes and objects by custom condition and supertype; and searching of functions by custom condition and signature).

Since we use IR generation, the plugin can be used by all platforms (JVM, Nativa and JavaScript). Although currently, we can analyze only kt files.
Additionally, the plugin uses a code generation approach in limited DSL to support compile-time reflection in libraries. It means, if you have a library that uses Reflekt and you call something from this library in your project, all Reflekt calls will be in the compile-time.
Currently we support 1.5.30, 1.5.21, 1.5.20, 1.5.10, 1.5.0 Kotlin versions.
Unfortunately, we do not support incremental compilation yet, but in the next release, we will be!

We will be happy if the plugin would be helpful for you! If you are interested in this project and have some ideas for improving the plugin, please don’t hesitate to contact me!

[Zac Sweers]

this is really cool! I wrote a basic annotation processor at one point in our project to do something similar for a subset of cases, hoping we can just replace that with this. Would the long term goal of this be to eventually supplant the need for kotlin-reflect for applicable places?

[Zac Sweers]

One thing our processor does that I don’t see an option for in reflekt is the ability to get a sealed class’s subtypes. Would that be worth filing a feature request for?

[mcpiroman]

I suggest you post this in #feed

[Anastasia Birillo [JB]]

@Zac Sweers Thank you a lot!
Likely yes. Of course, we can not move all reflection queries into compile-time, but I think we can move a part of them and in these places replace kotlin-reflect to reflekt in the future.

Initially, we developed this plugin to replace runtime reflection into compile-time in Kotless (https://github.com/JetBrains/kotless) and many from the current features were chosen to solve this task.
We would be happy to expand our DSL to add the ability for other reflection queries if it is necessary for someone. You can open an issue in the repository and describe your case in more detail.

Currently, we are working on the task to support incremental compilation to decrease the compilation time if Reflekt is used. Additionally, we are thinking about compile-time code generation for instances that were found by Reflekt.

[Fleshgrinder]

Looks very interesting and useful, we are using reflections for this today. Looking at the getting started part it looks like a lot of work to get this into a Gradle build with all the configuration fiddling. I guess this will be resolved, as I'm sure it hurts adoption.

Not sure if code generation isn't feature/scope creep. I have the impression that a lot of people build compiler plugins, just to offer code generation. Wouldn't it make more sense to invest into a macro system as part of Kotlin, so that not everyone needs to reinvent this? Maybe I'm missing something here that reflekt could provide in terms of code generation that wouldn't be possible otherwise?

[edrd]

Awesome, especially for K/JS given its reflection library is very basic

[Anastasia Birillo [JB]]

@Fleshgrinder Thank you for your feedback! Probably we have to change it, I will create an issue with this task.

Oh, sorry, without details it really looks strange! Lets me tell you about our idea in more detail. I mean we are thinking about creating something like macro, yes. The main idea is a user can write code that should be generated in the compile-time and we have an understandable and convenient interface for it. It is something like DSL for any code generation in the compile-time.

[Fleshgrinder]

Great 👍

Yeah, macros, this should really become part of the language itself so that anyone can use them right of the bat. Having it in reflekt means that either every other plugin needs to depend on reflekt (although they don't need it's capabilities), or everyone roles their own solution to expand code at compile-time. I think reflekt should concentrate on what you have described: collecting information about the codebase according to predicates so that we don't have to collect it at runtime. The reflections library is doing that and only that, but even with that limited scope it has managed to become an integral part of the entire JVM ecosystem. Simply because this tiny feature set is so tremendously useful on its own.

Hence, having a do one thing, do it good cross-platform solution for exactly that in Kotlin that integrates nicely would already be a tremendous achievement. Ideally moving into maintenance mode very quickly; stability is king. 🙂

Proper macros (compile time code generation) is a massive beast, and getting the soundness and IDE support right is an unbelievable task. The Rust community is working on this since pretty much the inception of Rust, and it's still one of the most complicated parts of the language. Plus, still a major headache for IDEs to make sense of.

[Anastasia Birillo [JB]]

I got it, it is an important point, thank you a lot! We will discuss this with the team, who is a part of the Reflekt plugin. Your arguments got me thinking and maybe re-prioritizing the current tasks.

By the way, the most important thing now is to support incremental compilation and we have some time to think about the development direction for the plugin 🤗

Oh, about IDE - it is really our pain since we have to develop a plugin for Idea to highlight parts that would be called in the compile-time. I mean you can get the list of some functions and next call each of them. In this case, the query that collects this list will be called in the compile-time, but each call for each function will be called in the runtime

[Fleshgrinder]

Incremental is a must for me to give it a spin, clearly most important. 😉

Yeah, that's very complicated, especially with the configuration residing in Gradle.

[Anastasia Birillo [JB]]

I hope in the next release we will finally support IC 🙏

[Youssef Shoaib [MOD]]

It feels as though there's some boilerplate in the configuration don't you think? the resolution bit, and depending on the dsl library feels entirely useless. For the resolution, if you use the gradle-publish-plugin, then you can just use the normal id for it without needing all the resolution stuff. For the dependency on the dsl library, you can add that in the gradle plugin itself and it'll resolve automatically (IIRC IDEA used to not understand that but that bug is solved now).

Also the gradle plugin can turn off incremental compilation on its own

[Anastasia Birillo [JB]]

@Youssef Shoaib [MOD] Thank you! Yes, sorry, I will fix README and make the installation process and all things connected to this problem easier in a couple of days
I created an issue about it, but I caught a cold over the weekend and did not manage time to fix it 😞