Consider adding nullness metadata to javaslang

[nfekete]

Nullness annotations are class level metadata, they are stripped at runtime, which should imply that they are not needed at runtime (this assumption needs some investigation). If they are indeed not needed at runtime, javaslang might depend on them as a compile-time-only dependency (using <optional>true</optional>) without dragging them transitively when imported into a project.

GWT version might be an exception as the GWT compiler needs access to the sources when compiling, thus it will try to look up the sources for the nullness annotations and probably fail if it won't find them. We could try telling the GWT compiler to just ignore them, that would solve the issue, but I'm not sure if it's possible.

[danieldietrich]

Note: All incoming features are targeted to 3.0.0 until the current 2.1.0 are finished. When we ship 2.1.0-beta we will pick features from 3.0.0 that should be part of 2.1.0-RC1.

[danieldietrich]

See also #1701

[rkraneis]

@nfekete How do you want to tackle null (and possibly other checks)? A good tool seems to be the checker framework which supports basically arbitrary checks (e.g. purity) besides nullness. The good thing (or bad, depending on your viewpoint) here is, that the checks are done during the build (and will fail it) and not only exist as hints in the IDE (an eclipse plugin also exists, never used it though). It also lets you add annotated shims for not annotated libraries (e.g. the jdk).
Edit: this might be an issue :-/

[nfekete]

I'm using the null analysis capability built into Eclipse. See Null Analysis on Eclipse Wiki and Using null annotations (pay attention to all 3 subchapters about null annotations, particularly about null type annotations and external null annotations).

Null analysis in Eclipse seems to be the most powerful from the solutions out there, although I admit I haven't played much with other solutions. I tried with IDEA, but I couldn't make it work and I gave up after a short while as I'm using Eclipse anyway. I'm willing to give IDEA another shot when I'll have more time to see if it could be made it possible to share the same annotation metadata across Eclipse and IDEA.

I also used the LastNPE eclipse plugin which helps in automatic configuration of external annotations for maven projects, which somehow was left out of the original eclipse solution. Without this plugin, the external annotation configuration would be completely manual in Eclipse and it would be a huge pain in the ass.

To me, null analysis was a great success, although it's not without it's own glitches. But I expect those will be solved in later releases. I have way less NPE problems now than before, and I think it improved my coding in the sense that now I do the most I can to avoid even the possibility of null references in my code in the first place. Also, I feel that going all in with it is the best approach, since if you don't change your coding style and you mix null with non-null a lot in your code, it will be pretty annoying, with nullability annotations all over your code. But I consider that as a positive as it will push you towards cleaning up your code and move away from nulls. For me the best approach was to declare non-null at a package level and only do very rare @Nullable exceptions, or none at all if possible (performance critical code might warrant using one less indirection and use null instead).

I didn't try out the Checker Framework, so I can't say anything about it. They say they support Eclipse's annotations, so I might give it a try on some existing project to see what it does.

[m-titov]

https://github.com/uber/NullAway

[danieldietrich]

We unclutter Vavr 1.0 and remove all non-native annotations.