Spring-ai Add Kotlin reflection support to ModelOptionsUtils

As documented via #1666, schema generation from Kotlin classes currently requires using non idiomatic code like data class Foo(@get:JsonProperty(required = true, value = "output") val bar: String) while the required information can be inferred from Kotlin null-safety and the value inferred from Kotlin reflection.

A related com.github.victools.jsonschema.generator.Module instance could be implemented and created when KotlinDetector.isKotlinReflectPresent() == true to provide those information automatically here.

That would allow to perform schema generation with just data class Foo(val bar: String).

Comment From: devcrocod

Hi,

I have some question regarding this issue, please clarify follow points:

In a data class like data class Foo(val bar: String, val baz: String?), should the property baz be not marked as required in the generated JSON schema because it's nullable, even though it doesn't have a default value? Or should it only be considered not required if it has a default value, like in data class Foo(val bar: String, val baz: String? = null)?
Also about properties with default values: How should the module handle non-nullable properties with default values, such as in data class Foo(val bar: String, val baz: Int = 10)?
Should the same logic be handled for functions?

Comment From: sdeleuze

Hi, thanks for your feedback.

I think conceptually the goal is to infer if a property is required or not, so I think I would consider both nullable properties and properties with default value as non required, and the other ones as required. So for your 2 examples, only bar is required.

For functions, I think that's outside of the scope of this issue. It could make sense to use Kotlin reflection instead of Java one to support more advanced Kotlin constructs, but so far I don't think there is advanced need for optional parameters with default values as only Function1 and Function2 are supported. Could be useful for suspending functions potentially, but that's a different need so I would suggest to focus on schema generation initially, and explore more advanced function invocation later.