Feature Request: Allow loading classes

[lineargraph]

While loading objects is quite nice, i find myself wanting a mix of objects and regular classes for some particular interface. This can be achieved right now by having an @Service and a regular java ServiceLoader in one. The ServiceLoader will then be filled (using AutoService, for example), while the objects will be loaded using the sweet spi service. Maybe it would be possible for the sweet spi to also already load objects from the regular service loader? That would also make it possible to implement sweet spi services from java. Even if that option is not an option, just allowing the plugin to generate instances for a service would be nice.

[whyoleg]

Hey!
Agree, for uniformity and compatibility it should be supported.
I've recently started to investigate better compatibility with JDK platform, e.g. using ServiceLoader more natively, but it needs more research and most likely usage of compiler plugin to continue be fast on Android.

Still, it's in early stage, as I'm trying to understand use-cases and may be there are better alternatives to ServiceLoader in KMP, as every dependency is available at run-time. So may be some other explicit way to configure providers will be better in the end :)
Sharing your experience and use-cases will be very valuable and can be done here: #9

[lineargraph]

Hi!
To clarify what i meant yesterday (as i don't think it is particularly clear): I know that javas ServiceLoader checks for constructors being present (excluding of course static provider methods, but those require JPMS and are also not commonly found in objects). So going the "loading kotlin objects from the java service loader" route isn't easy. What i actually wanted is for classes that would regularly be loaded from the java ServiceLoader, to also be loaded and instantiated from sweet spi. This would, in essence, be as easy as SweetServiceLoader.load<MyService>() + JavaServiceLoader.load(MyService::class.java).toList(), which would allow java code to also provide interfaces without any kotlin plugins required. This would, of course, only really make sense if the sweet SPIs ServiceLoader itself allowed for loading classes by instantiating them, so i am thinking of that as an issue to be resolved before.

[rnett]

+1 for both of these, especially the ability to use classes with default constructors as service providers.

[rnett]

I can make a PR for these if you like, the implementation seems straightforward.

[whyoleg]

I can make a PR for these if you like

Yeah, sure, go for it!

Note: adding support for kotlin classes in KSP will still not allow consuming Java classes via sweet-spi because of how it works under the hood.

[rnett]

PRs up.

[rnett]

RE #16:

I'd propose:

• Add a loadPlatformServices(service: KClass<out T>): List<T> method to InternalServiceModule. It's generated implementation will contain a when with every service class of that module that calls internalLoadPlatformServicesHelper($ServiceClassConstant::class)
• Add a public-but-opt-in-annotated inline expect internalLoadPlatformServicesHelper(service: KClass<out T>): List<T> that on JVM, calls ServiceLoader.

Taken together, internalLoadPlatformServicesHelper will be inlined into the loadPlatformServices when statements, which should allow R8 to optimize it. We'd want to maintain a serviceModules: Map<KClass<*>, Set<InternalServiceModule>> in InternalServiceLoader so we don't need to look through every module.

[whyoleg]

Answering to the above:
I believe that a more effective approach would be to eliminate InternalServiceModule entirely and redesign the API around the class itself, thereby eliminating a single global registry. This will also be more aligned to have JVM implementation work.

In this case, we will generate something like ClassNameServiceLoader function for each service (or extension on companion, TBD).

However, I do think that overall, for JVM-only use cases, it might be much easier to simply use Java ServiceLoader.
The library attempts to conceal the complexities of the SPI-based approach. On one hand, it's sweet, but on the other hand, it might not be the best way forward for the Kotlin Multiplatform ecosystem.