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

Add nullability annotations in generated Java code #63

Open
rbell-mfj opened this issue Jan 13, 2023 · 3 comments
Open

Add nullability annotations in generated Java code #63

rbell-mfj opened this issue Jan 13, 2023 · 3 comments

Comments

@rbell-mfj
Copy link

Generated Java code would have better null safety when used in Kotlin if there were an option to add nullability annotations

@rbell-mfj
Copy link
Author

If I could get support from my employer to have someone contribute this, is there someone around here to accept a PR? Looks like the last PR merged in this repo was June 2021.

@ucarion
Copy link
Contributor

ucarion commented Jan 16, 2023

Is the ask here to make it possible to customize what annotations jtd-codegen would use to indicate nullable/non-nullable fields?

And yes, I can accept PRs.

@rbell-mfj
Copy link
Author

rbell-mfj commented Jan 17, 2023

Is the ask here to make it possible to customize what annotations jtd-codegen would use to indicate nullable/non-nullable fields?

In short, yes.

The immediate goal is to have a way to add nullability annotations that allow the Kotlin compiler, when reading Java code generated by jtd-codegen, to know whether a property is nullable or not. (By default, it treats all Java types as unchecked with regard to nullability). The list of supported annotations for this is here

These would need to be in addition to the existing Jackson annotations.

Customizable sets of annotations for nullable/non-nullable is perhaps the best way to do this as it would enable other use cases.

That said, a simple on/off switch for one predetermined type of nullability annotation (from the list linked above) would also achieve the goal, if we could identify one that made sense as a de-facto standard or most commonly used.

Do you have a preference?

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

2 participants