Create JVM compatible versions of suspend functions. Add annotations to replace names in JVM compiled libraries.

[adrian-lorenzo]

This PR temporarily solves #47.

It includes fixed methods of SemanticSearch class that are compatible with JVM since it generates CompletableFuture from the GlobalScope.

This mechanism does two different things:

1. It generates two types of functions: one using coroutines, and another one using Java virtual threads with CompletableFututre.
2. It changes the names in JVM compiled libraries to make the default solution the one compatible with Java.

If someone generates new suspend functions that are callable in the API, they would need to follow the same process.

A metaprogramming solution like the generation of an annotation processor to generate code on compile time is needed to solve this easily without code repetition. For example, creating a @JvmCompletableFuture annotation and a code processor.

[juanjoman]

LGTM! Although I think there's a type issue in the Handler parameters. If we use this:

Function<SearchInput, Unit> handlerFunction = (SearchInput s) -> {
            try {
                return semanticSearch.learn(s).get();
            } catch (InterruptedException | ExecutionException e) {
                throw new RuntimeException(e);
            }
        };
        // JvmClassMappingKt.getKotlinClass
        Handler<SearchInput, Unit> writeHandler = new Handler<>(
                "learn",
                SearchInput.class,
                Unit.class,
                handlerFunction
        );

The classes are not Kclass, but Class (Java). This is an issue in the Function<SearchInput, Unit> declaration, which I'm trying to solve now 🤔

Could you try this??

[juanjoman]

Not a Kotlin expert but I was reading that using CoroutineScope is more correct and less "delicate" (you can remove the @OptIn annotation):

CoroutineScope(EmptyCoroutineContext).future { learn(input) }

[adrian-lorenzo]

Your problem seems to be related to a problem that is not part of the function created. Probably because of the usage of Kotlin functionalities that are not compatible with Java.

Also, CoroutineScope seems to have the same problems as GlobalScope, and it is not recommended to be used by Kotlin's official documentation.

[javiertoledo]

I'm not fully convinced on doing this. If we enable Kotlin Multiplatform, that generates many additional packages in which we could put specific integration code for each platform. Maybe adding the code for the JVM there could help to keep things clean while using idiomatic Kotlin for the core implementation...