Add nullability annotation for kotlin interop.

[jaychang0917]

Currently the oldState will be interpreted as nullable in Kotlin like:

class TestAction: Action<String> {
  override fun newState(oldState: String?): String {
     // ...
  }
}

This PR adds nullability annotation for better nullability interpretion in Kotlin.

[codecov-io]

Codecov Report

Merging #45 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master      #45   +/-   ##
=======================================
  Coverage   94.59%   94.59%           
=======================================
  Files           5        5           
  Lines          74       74           
  Branches        5        5           
=======================================
  Hits           70       70           
  Misses          3        3           
  Partials        1        1

Impacted Files	Coverage Δ
...rox-core/src/main/java/com/groupon/grox/Store.java	100% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 330a0ad...72d6c94. Read the comment docs.

[chenthorne]

Is this actually true though? In Java land, why couldn't you have a null state?

If we want to enforce a non-null state need to update annotations for the appropriate Store classes too.

[jaychang0917]

In UI world, null state doesn’t make sense.

…

On Tue, 18 Dec 2018 at 9:39 AM, Cody Henthorne ***@***.***> wrote: Is this actually true though? In Java land, why couldn't you have a null state? If we want to enforce a non-null state need to update annotations for the appropriate Store classes too. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#45 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFGYzyBZdY1_V2Guq0sqdXck4jIweTMGks5u6EdbgaJpZM4ZUvAa> .

[chenthorne]

Don't get me wrong, I'm for the change as I have the same problem in kotlin too but I could understand that a null-state could be a thing.

Grox isn't UI specific just helpful for it, it's just state management.

[chenthorne]

If you're up for more annotations, I'd support adding them to the Rx classes as well :)

[stephanenicolas]

It looks like we're all on the same page. I agree with you Cody, it could have made sense to have a null state. But I see that it's more a technical constraint to remove this possibility. Anyway, it looks like with Kotlin being introduced, we're just starting to wonder all the time why we would support something null.. :) Le mer. 19 déc. 2018 à 03:08, Cody Henthorne <[email protected]> a écrit :

…

If you're up for more annotations, I'd support adding them to the Rx classes as well :) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#45 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABv33Z8rrkhTzlfSKvc-ArwiIAqpRyfCks5u6Z-ngaJpZM4ZUvAa> .

[alin-turcu]

Looks good on my side also. I don't think a null state would make much sense. I would rather have a "empty state" than a null one.