Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kotlin null-ability #115

Open
mykolapolonskyi opened this issue Sep 19, 2016 · 4 comments
Open

Kotlin null-ability #115

mykolapolonskyi opened this issue Sep 19, 2016 · 4 comments

Comments

@mykolapolonskyi
Copy link

I`m trying to provide the JSON schema generation for Kotlin data classes/classes that have specific null-able behaviour:

var string: String - can't be null
var string: String? - can be null

Is there specified mechanism for recognizing this types? Or perhaps you plan any kind of support it in future.

@mykolapolonskyi mykolapolonskyi changed the title Kotlin null-ability and stdlib Kotlin null-ability Sep 19, 2016
@cowtowncoder
Copy link
Member

@GLHF Schema module has no knowledge of these differences, as it relies on information sent by jackson-databind (for standard types), and in case of Kotlin further modified by jackson-module-kotlin.
So I think this should be filed for that module; it can not be resolved by modifications to this module (although there is sometimes follow-up work for some edge cases).

@cowtowncoder
Copy link
Member

/cc @apatrida

@apatrida
Copy link
Member

This is for schema generation? Currently the Kotlin module does not provide this information externally, and uses it on the fly when instantiating objects to decide whether there is a problem between the available JSON object properties and the class being instantiated, or whether it should use the default values for optional parameters to constructors.

If there is pluggin-ability to the schema generator to provide more information when introspecting a bean/class, then I can add the Kotlin specific knowledge (would require Kotin + possibly Kotlin-reflect if not able to use reflect-lite). This otherwise might require adding the ability to add modules to this module (plugin to the plugin), or adding the Kotlin dependencies and one Kotlin file to do the Kotlin type handling (it is easy to detect a Kotlin class, and then reflection is easier there, in fact introspecting Java Beans is easy from Kotlin because all of the work is done in the reflection library to identify the bean information)

Sorry, I don't know this module more to know the best path for someone to add this. The code on the Kotlin end is probably the easy part, its plugging it in that is unknown.

@cowtowncoder
Copy link
Member

@apatrida Thank you for the notes. I don't know if this is feasible to support either... and the whole introspection system is a mess, unfortunately (... contribution which was unfortunately based on earlier schema generator, which is too JSON-Schema-specific...).

Schema generation relies on information passed via acceptJsonFormatVisitor(), in general, but optionality/requiredness is based on whether required property is set for BeanPropertyWriter, accessed through BeanProperty.isRequired().

This information ultimately comes via AnnotationIntrospector:

public Boolean hasRequiredMarker(AnnotatedMember m) { return null; }

which may or may not help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants