Use KotlinX instead of GDX for JSONs?

Neither a bug report nor a feature request.

AFAICT, the GDX JSON tools used by JsonParser.kt work by creating new instances of classes, with zero arguments, and then assigning values to their members from the JSON file.

It was also designed only for Java, I believe, and does not support Kotlin-specific idioms/features.

This seems to create several limitations:

• No support for data classes.
• Requires default initializers for all properties. (Adds noise to code, leaves room for silent failure if the .JSON fails to define some required value.)
• No support for immutable val properties. (Again, creates unnecessary room for silent failures.)
• No/poor support for deserializing into interfaces/arg-requiring constructors. (E.G. Map<>, probably List<> and Array<>.)
• Ugly SomeClass::class.java syntax.

For the IPC protocol in #5608, I decided to go with the official KotlinX serialization library as standards compliance is more important there, and it’s been great for (de)serializing objects with known structure.

KotlinX also describes itself as supporting a “lenient” deserialization mode, which looks like it should be largely compatible with the “Javascript” and “Minimal”-style unquoted JSON files currently parsed with GDX (and you can write custom deserializers too, though I found it a bit painful to do so):

https://github.com/Kotlin/kotlinx.serialization/blob/master/docs/json.md

Might it be a good idea to switch JsonParser to use the official KotlinX JSON tools instead of GDX?

Comparisons

KotlinX:

data class TileSpec(
	val tileYield: Map<String, Int>,
	val someList: List<String>,
	val immutableNumber: Int
)

val tileSpec = Json().decodeFromString<TileSpec>(jsonString)

GDX:

class TileSpec() {
	var tileYield = HashMap<String, Int>()
	var someList = ArrayList<String>()
	var immutableNumber = 0
}

val tileSpec = Json().fromJson(TileSpec::class.java, jsonString)

IMO the biggest thing is (apparently) being forced to use mutables. Most stuff that gets loaded from JSONS is probably also stuff that shouldn’t ever change.

---

Some of much of this may just be incorrect usage on my part, but I’m not sure how much if any.

[yairm210]

So yeah, this is a no-go in the core project from a cost benefit perspective

[will-ca]

@logicminimal He said “cost-benefit”, so… The benefit’s also fairly small, just some minor syntactic and semantic QoL improvments. And in addition to the size, a lot of (if not most of) the existing classes would also have to be changed to make use of it, so the cost is pretty major if you’re not rounding your available resources up to ∞.