Open connyduck opened 1 year ago
Hello @connyduck,
good to see you here again.
Currently, we are migrating to new Kontent.ai services (in this particular case new GitHub organization and Maven package identification).
Once we finish that, I will reach out with the proposal. Do you have a suggestion on which nullability annotation would be the best to use?
One more question - what are the most important classes you wold like to see the nullability annotation first?
Once we finish that, I will reach out with the proposal. Do you have a suggestion on which nullability annotation would be the best to use?
I don't really care since they all work they same for consumers. org.jetbrains.annotations
is probably the most widely used one, and you already have it in StronglyTypedContentItemConverter
so that is probably the logical choice.
One more question - what are the most important classes you wold like to see the nullability annotation first?
How about starting with the DeliveryClient
itself, then the ContentItem
and on to the different elements and assets?
Motivation
The Kentico Delivery Client and its model are treated as platform types in Kotlin, which makes them harder to use and increases the possibility of accidental NullPointerExceptions.
Proposed solution
All public methods have annotations on parameters and return types so that the Kotlin compiler can correctly infer their nullability and prevent unchecked use of nullable types. This is also an improvement for Java callers, usually tools emit a warning when nullability is handled the wrong way.
Additional context
Nullability Annotations supported by the Kotlin compiler and more info how calling Java from Kotlin works: https://kotlinlang.org/docs/java-interop.html#nullability-annotations