All public APIs already document in their Javadoc whether they accept null values as parameters and whether the may return null. However, this information isn't currently machine-readable and therefore IDEs cannot assist developers that program against these APIs. This may lead to unexpected NullPointerExceptions and leads to unnecessary casts and assertions when writing code in Kotlin because it differentiates between nullable and non-nullable types. Therefore, we should mark all our non-internal code with annotations that are interpreted by IDEs as well as the Kotlin compiler. Moreover, we should change our build to validate the consistency of these annotations.
Related Issues
Deliverables
All public APIs already document in their Javadoc whether they accept
nullvalues as parameters and whether the may returnnull. However, this information isn't currently machine-readable and therefore IDEs cannot assist developers that program against these APIs. This may lead to unexpectedNullPointerExceptionsand leads to unnecessary casts and assertions when writing code in Kotlin because it differentiates between nullable and non-nullable types. Therefore, we should mark all our non-internal code with annotations that are interpreted by IDEs as well as the Kotlin compiler. Moreover, we should change our build to validate the consistency of these annotations.Related Issues
Deliverables