Closed DontingK closed 1 year ago
Not sure why there is no original issue description, but we can assume this issue is requesting support of the Java language.
Well i guess we have to be more specific about it. As Java can most probably already be used if the godot interfacing classes are written in kotlin. The rest could probably be in java already. That said, i guess we can introduce a meta issue for java support (or other languages in general, which would remove the need of keeping #242 open and provide general information on what is needed to implement support for other languages).
But as of now, supporting other languages is not a priority for us at this stage, as we first want to stabilize and complete this module. After it's stable and feature complete to a certain degree, we can look into it. That said, if one want's to volunteer implementing another language, why not.
To summarize: i propose to introduce a meta issue for other languages in general and in turn close this issue and #242
I aggree with @chippmann proposal.
Maybe we can prepare a clean doc for adding other JVM languages support while reworking for 4.0
?
Hello, I came for "If you want to add support for another Jvm based language (...) we'll explain in detail what is necessary to support another language and help you getting started with development" part of the docs. Do this documentation already exists?
Quick update on this: Now that #433 is merged and once #441 is merged, we can finally support java out of the box (as our symbol processor, which is based on ksp, already supports it by now: https://kotlinlang.org/docs/ksp-faq.html#is-ksp-kotlin-specific). After the godot 4 adaptation is fully complete (which should not take long anymore), I'll work in initial java supports as some minor work is still needed:
@JvmName
where neededI'll do an initial implementation for java by implementing the tasks marked with *
the checks are QOL features which can come at a later date as well as the documentation.
Stay tuned for updates.
I think we will need another @RegisterProperty
annotation implementation for private field with getter and setter.
I know there is no template issue. But an issue description would be nice.