A modern programming language that makes developers happier.

kotlinlang

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

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. 

<https://github.com/hfhbd/serviceloader-gradle-plugin|https://github.com/hfhbd/serviceloader-gradle-plugin>

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

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?

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.

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
• <https://github.com/whyoleg/cryptography-kotlin/blob/main/cryptography-providers/jdk/src/jvmMain/kotlin/JdkCryptographyProvider.kt#L64|JVM provider injection>
• <https://github.com/whyoleg/cryptography-kotlin/blob/main/cryptography-providers/webcrypto/src/jsMain/kotlin/WebCryptoCryptographyProvider.kt#L42|JS provider injection> (super very hacky)
• <https://github.com/whyoleg/cryptography-kotlin/blob/main/cryptography-providers/openssl3/api/src/commonMain/kotlin/Openssl3CryptographyProvider.kt#L45|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 :slightly_smiling_face:

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

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

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. 

this is exactly what I was looking for!
<@UE4SM1QEB> I opened an issue on <https://youtrack.jetbrains.com/issue/KT-63218/EagerInitialization-use-cases|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

I will warn one more time: this is super-duper hacky solution :slightly_smiling_face:
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...

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

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