Does a multiplatform alternative to Google's AutoService annotations/annotation processor exist?

# multiplatform

[martmists]

Does a multiplatform alternative to Google's AutoService annotations/annotation processor exist?

[hfhbd]

Yes, I created a Gradle and KSP plugin, but it still uses JVM ServiceLoader mechanism, so you can add the annotation to your mpp code, but only use it from JVM.

[hfhbd]

https://github.com/hfhbd/serviceloader-gradle-plugin

[martmists]

You don't happen to know of any alternatives that do offer their own ServiceLoader?

[hfhbd]

There is no native implementation because this would require reflection, which isn’t available at native or JS. But this should be doable with KSP. Could you describe your use case?

[martmists]

I'm working on a multiplatform application (android, jvm, web) where I'd like to include a plugin framework. Due to how it's designed, these plugins should be available as soon as possible at runtime, but as there's no global constructors in Kotlin I'm not sure what approach would be best.

[Oleg Yukhnevich]

it’s somehow possible to create ServiceLoader like MPP approach using K/N and K/JS EagerInitialization annotation.
for inspiration you can take a look at how I’ve handled it in https://github.com/whyoleg/cryptography-kotlin
• interface for providing implementations - https://github.com/whyoleg/cryptography-kotlin/blob/main/cryptography-core/src/commonMain/kotlin/provider/CryptographyProvider.kt
• check actual platform declaration of defaultCryptographyProvider for more info
• JVM provider injection
• JS provider injection (super very hacky)
• Native provider injection (a little less hacky)
I was thinking about generalising it in form of compiler plugin, though never had time to do it 🙂

[hfhbd]

Yes, but keep in mind EagerInitialization is only a temporary solution and will removed in further Kotlin releases.

[Oleg Yukhnevich]

yeah, that’s true, though, it’s the only way to handle such functionality now
I believe, that there should be some replacement before it removal

[hfhbd]

Depending on your usage, if this is your executable, you could just call it in the main function. If you develop a library, there is only the hacky workaround mentioned before.

[elect]

this is exactly what I was looking for!
@Oleg Yukhnevich I opened an issue on youtrack with your use case (which I'm gonna use it right away) in order to avoid this annotation from getting removed before a proper solution is in place

[Oleg Yukhnevich]

I will warn one more time: this is super-duper hacky solution 🙂
In my case it's fine, as even if this functionality will be removed ( I mean EagerInitialization annotation), library will be still easily usable with direct invocation of providers. Or users will be able to provide explicit expect/actual for provider they needed
So, you are warned...

[elect]

did you investigate, in the meanwhile, into an alternative solution, though?

[Oleg Yukhnevich]

AFAIK, there is no alternatives for my use case
not sure, what alternative solution could be - explicit call for init default variable may be?