I have a few questions if someone could assist: I want to generate adapters between an internal representation of data and a data class so I can do something like

DataClass.from(internalRepresentation)

without requiring developers to hand write the

from

adapter. I would do this using annotation processing but there's data missing in the kapt Java stubs (default values). I want to eventually add some validation as well, but generating adapters is the first step. 1) How safe would Arrow Meta would be for doing this for production? ie. How likely are there to be breaking API changes (especially non-trivial ones). I know there's some compiler revision going on right now so there's potentially a lot of uncertainty. 2) Is it reasonable to want to use Arrow Meta/a compiler plugin to do this? 3) Is it possible to use Arrow Meta like an annotation processor to generate code/classes for this rather than interacting more directly with the compiler (the examples I see are focused on transformation rather than generation)? (Generated code would provide a better plan B in case the plugin breaks at some point). Nevermind this one, just found the answer (yes).

Hi Derek,

1) How safe would Arrow Meta would be for doing this for production? ie. How likely are there to be breaking API changes (especially non-trivial ones). I know there’s some compiler revision going on right now so there’s potentially a lot of uncertainty.

Arrow meta from here on will follow compiler releases and will release the first stable version when the compiler makes the IR backend non-experimental which also others like Jetpack compose are waiting for. From that point forward as in any compiler plugin they are always tied to the compiler runtime so you also will have to release each time the compiler releases until they provide a public stable API.

2) Is it reasonable to want to use Arrow Meta/a compiler plugin to do this?

Yes, you can already use meta to access the precise typechecked info of a data class without the java stubs limitations you find in kapt and use meta to generate new sources or transform the IR tree before code generation.

Thanks you for the very detailed response! I think I'll give it a try and see what I can manage.

IR is the future of Kotlin if you don’t depend on IR then you have to provide ASM or similar for your plugin which is ment to be faded out, so that’s the other risk and why we are all waiting on IR

Ah. It seems like it was possible to produce Kotlin source files, which shouldn't inherently be dependent upon the IR? I guess arrow meta is dependent on the IR for making calls to whatever plugin I write though.

No, that is possible