Add null-safety to the Flowable API

1

Recently more and more frameworks are adding null safety to their API (by utilizing the JSR 305 annotations). I think adding something like this to the public API and the internal API can help developers and maintainers of the project.

More details can also be found in these 2 Square blog posts Rolling out @Nullable and Non-null is the default. Another good place with a lot if information is the SPR15540 (the issue that Spring used to add this to their API).

Yes a lot of frameworks have added it because of Kotlin, and I am not sure if people using Flowable are using Kotlin, but still I think that the benefits are quite big. IDE support for the annotations is really good as well and is out of the box.

I would like to know if this is something that is worth pursuing within Flowable.

2

A few questions/remarks:

  • It probably only really makes sense for the public API (the services and such)
  • What kind of IDE benefits does it bring?
  • Most (if not all) of our API’s will not accept null. What added value would then adding @Nullable bring?
  • The number of dependencies of the core engine is kept to a minimum, I’m assuming this brings in one or more additional dependencies?
3

I think it makes sense for both:

  • The public API users will get notified by IDE that they are passing null for a not nullable parameter. And also the return types.
  • We as developers would more easily code and get better support from the IDE, like redundant null checks, missing null checks etc.

What kind of IDE benefits does it bring?

Well you get warnings in the IDE if you pass null to a not nullable method, or you dereference a nullable return value without checking it.

Most (if not all) of our API’s will not accept null. What added value would then adding @Nullable bring?

That is great :smile:. There is a package level annotation that says my entire API and parameters are not null, which means that users will get warnings on all places where they pass null value and we are expecting not to be null. The @Nullable will just let them pass nulls.

The number of dependencies of the core engine is kept to a minimum, I’m assuming this brings in one or more additional dependencies?

There would be Flowable Nullable annotation that would be have the JSR 305 meta annotations. The JSR 305 annotations dependency can be optional. IDEs and Static checker tools add it as a dependency during their checks. Which means that we won’t need to pull it transitevely (Spring is doing that in 5.0).