Thorough check on nullable/non-nullable arguments

[aalmiray]

For example DeferredRunnable(StartPolicy) does not check if its argument is null or not, perhaps assign a default value just like DeferredCallable does.

It might be a good idea to state the nullability of arguments and return types. This has been done in part in DeferredManager on the type safe versions of when, race, and settle.

[saturnism]

thinking of using FindBugs and JSR 305 annotations, and going through all the input params thoroughly on DeferredManager and callbacks.

Should we do this before or after #157?

[aalmiray]

I'm a big fan of JSR-305 and I use whenever I can. This being said there are a few problems with it https://blog.codefx.org/java/jsr-305-java-9/

I think it would be better to perform a static analysis of the code without applying annotations to the source. We can do this with Findbugs and IntelliJ (both of them).

[saturnism]

eak :( what should we use?
There are several options that can provide kotlin interop - https://kotlinlang.org/docs/reference/java-interop.html

[aalmiray]

The thing is, if we choose existing @Nonnull/@Nullable we'll add an extra dependency to JDeferred, right now core only depends on slf4j-api. What worries me by bringing JSR-305 is the fact that someone may get in trouble setting up JDeferred with the module system.

[saturnism]

hm, can it be an optional dependency? i.e., in normal cases and be optional during the runtime?

[aalmiray]

The annotations from JSR-305 have runtime as retention policy. I'm afraid adding it's not possible to add them as an optional dependency.

[saturnism]

doh! will put that on hold then, and just add null checks