Add JVM/JNI target for local development

Describe the problem or limitation you are having in your project: The Kotlin/Native compiler is very slow at present, resulting in fairly long turnaround for small game code changes using godot-kotlin during development.

Describe how this feature / enhancement will help you overcome this problem or limitation: For local development, running game logic on the JVM rather than native code would allow for quick re-compile times, as well as some JVM niceties such as live class reloading at runtime and direct debugging+breakpoints into the Kotlin code. The Kotlin/Native implementation in godot-kotlin can then be used in the exported game to remove the dependency on the JRE.

Describe implementation detail for your proposal (in code), if possible:

• Core+generated classes in godot-kotlin are extracted as Kotlin Multiplatform expect declarations. Native implementations of these classes will acquire actual keywords to define them as platform implementations, but otherwise remain unchanged.
• Kotlin/JVM actual implementations are created utilizing external methods to call out to Godot APIs; implementations will be registered by the JNI later.
• Game logic uses the same code as before, but for local development is compiled using the standard Kotlin/JVM compiler and the JVM actual implementations rather than the Kotlin/Native compiler against the existing implementations. The output classes are bundled to a JAR and output into the Godot project path.
• A GDNative library is created which links to the JDK. This library is relatively project agnostic and shouldn’t need to be recompiled during regular development. Upon gdnative_init, it instantiates a JVM via the JNI API, including the game logic JAR on the classpath. This initialization process also registers implementations for the JNI bindings above, allowing the JVM code to interface indirectly with GDNative. The implementations would be largely pass-through, but need to handle a bit of memory management and translation as the signatures for the external methods don’t support pointer types, etc.

Is there a reason why this should be in this project and not individually solved?: Ideally a JVM+JNI implementation will be maintained in parallel to the Kotlin/Native version to ensure seamless transition between fast local development and export.

[piiertho]

Currently kotlin native is not ready (see in readme). We are currently developping a jvm variant, in module way, so that is is better integrated in engine. Some code will be shared between the two repos, like entry generation, api generation and core types. See on https://github.com/Utopia-Rise/godot-jvm

[JustinMullin]

Sure, absolutely.