shall we use Kotlin?

[CXwudi]

• getter/setter problem - kotlin call from java link
• configuration properties data class - use init{} and the primary constructor should work
• Gradle? no, use Maven to speed up IDE's project build time
• JSON parsing, tree node approach, data class by map approach, or swagger with our own fixing approach?
  • if tree node, can we have [] operator working as getter and setter?
  • if data class by map, how to deal with field?? there is no tool to generate that kind of class. maybe we could write an issue for a JSON to kotlin plugin
  • if swagger, how is the maintainability? can it save time from the other two approaches?
  • An: swagger approach. it is good at having enums, proper time format. by doing our own fix, we help to make a great open-source vocadb client.
• so kotlin has special definitions for properties, does Java getters return type? or type? it is type, honor project poc proved it
• but with Xjsr305=strict, all @Nullable java function (including getter) wil return Type? in kotlin, which sometime is useful, sometime is annoying
  • An: depending on situation, either write orThrow() or just !!

[CXwudi]

We are now trying Kotlin in vvd-taskproducer

[CXwudi]

Our answer to Shall we use kotlin is

yes, but only on kotlin/jvm, where JSON models preferred to stay in Java.

[CXwudi]

At this time, vvd-taskproducer is pretty much done, and using Kotlin is a good success