# Nullable definitions for java library

**URL:** <https://discuss.kotlinlang.org/t/nullable-definitions-for-java-library/2375>\
**Category:** Language Design\
**Created:** [March 9, 2017, 12:33pm UTC](https://discuss.kotlinlang.org/t/nullable-definitions-for-java-library/2375 "2017-03-09T12:33:27Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![miguelangellv](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/miguelangellv/32/2432_2.png) [@miguelangellv](https://discuss.kotlinlang.org/u/miguelangellv)\
**Post date:** [March 9, 2017, 12:33pm UTC](https://discuss.kotlinlang.org/t/nullable-definitions-for-java-library/2375/1 "2017-03-09T12:33:27Z")

</div>

The most of java library don’t have the nullable annotations so the kotlin compilator can’t throw error with a possible null.

Will be interesting can add manually the annotations in our project as the extension methods.

```auto
@Nullable LibraryClass.fooMethod
@Nullable LibraryClass.barMethod

```

When you make the definition, the compiler throw error if you don’t check the null

```auto
val a = LibraryClass()
val b = a.fooMethod() //compilation error

```

---

<div class="post-metadata">

**Author:** ![fvasco](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/fvasco/32/1961_2.png) [@fvasco](https://discuss.kotlinlang.org/u/fvasco)\
**Post date:** [March 9, 2017, 1:17pm UTC](https://discuss.kotlinlang.org/t/nullable-definitions-for-java-library/2375/2 "2017-03-09T13:17:37Z")

</div>

Nullability can be often inferred using bytecode inspection or supporting custom annotations.

The ability to support metadata can improve compilation error’s detection, lack of metadata will back to platform type.

---

<div class="post-metadata">

**Author:** ![yole](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/yole/32/1425_2.png) [@yole](https://discuss.kotlinlang.org/u/yole)\
**Post date:** [March 9, 2017, 9:00pm UTC](https://discuss.kotlinlang.org/t/nullable-definitions-for-java-library/2375/3 "2017-03-09T21:00:09Z")

</div>

This was supported in pre-1.0 versions of the compiler and we dropped the support, because we don’t want the semantics of the code being compiled to depend on optional supporting files.

---

<div class="post-metadata">

**Author:** ![fvasco](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/fvasco/32/1961_2.png) [@fvasco](https://discuss.kotlinlang.org/u/fvasco)\
**Post date:** [March 10, 2017, 12:07pm UTC](https://discuss.kotlinlang.org/t/nullable-definitions-for-java-library/2375/4 "2017-03-10T12:07:49Z")

</div>

This choice is absolutely reasonable, however a better management of platform type should be helpful.

Using some kind of extra information leads to:

- IDE proposes right cast to Kotlin type
- IDE/compiler plugin shows a warnig for incorrect use of platform type (similar to Java @NonNull management)
- an external tool can fail build test phase

Managing this use case doesn’t require compiler modification.

---

<div class="post-metadata">

**Author:** ![NicolayMitropolsky](https://avatars.discourse-cdn.com/v4/letter/n/94ad74/32.png) [@NicolayMitropolsky](https://discuss.kotlinlang.org/u/NicolayMitropolsky)\
**Post date:** [March 18, 2017, 6:32pm UTC](https://discuss.kotlinlang.org/t/nullable-definitions-for-java-library/2375/5 "2017-03-18T18:32:43Z")

</div>

But at this moment Kotlin compiler doesn’t complain about not-annotated Java values. So if “optional supporting files” are missing everything will compile anyway, won’t it?

So I think it will be good to return this feature at least on _warnings_ level.