What does HackerNews think of NullAway?
A tool to help eliminate NullPointerExceptions (NPEs) in your Java code with low build-time overhead
https://docs.gradle.org/current/userguide/distribution_plugi...
> Null drives a big hole through whatever you try to achieve with the type system. Need a Key for this Lock? Open the Lock anyway, just find out at runtime that the Key was null, rather than at compile time.
https://github.com/uber/NullAway and bunch of rest.
* You can't express `T` where `null` is forbidden in the type system so you get NullPointerException everywhere and defensive null checks.
* You express a sum type as a product type because your language does not have sum types .
* Your language doesn't have first class multiple return values (or tuples) so you return extra parameters via out parameters or thread local variables such as `errno`.
* Your language doesn't have exceptions (or algebraic effects) and can't do IO so you have monad transformers.
* Your language doesn't have set-theoretic types so you need hacks like `thiserror` .
* Your language doesn't have stackful coroutines or can't infer async IO for you so you have `async/await` spam or callback hell or "mono's".
* Your language doesn't have exhaustive checks (or pattern matching) so you need a fallthrough case check on switch statements .
* Your language doesn't have algebraic effects, so you need to pass context everywhere.
I know someone will reply about Java's null annotation checking options, so here is one of them: https://github.com/uber/NullAway .
Disclaimer: I am one of the maintainers of one such tool, namely https://github.com/uber/NullAway
It certainly won't help with verbosity (in fact, it does the opposite to at least a small degree :)), but it can dramatically reduce the number of actual NPEs when running your Java code.
Obviously I am not saying this is a reason to not use Kotlin. But, when, e.g. based on the things mentioned elsewhere in this comment section, you are deciding to stick with Java for a particular codebase, it doesn't mean static null checking is not an orthogonal option to consider.
In any case, there already exist solutions in place:
Not a contradiction. Many of these tools are suitable for use in production, almost by definition, since they are being used in production, at Uber. They might or might not work in your environment out of the box. But they are certainly often likely a better starting point than an empty editor, even when they do not. Most of the ones I am familiar with, are happy to get PRs generalizing them to more varied environments.
> they're nothing more than interesting repos amongst a sea of interesting repos.
As someone who has open-sourced on GitHub: research prototypes hacked together for a research paper deadline in grad school, class projects, for-fun hacks, and also production tooling I built as a paid engineer, I'd say there is a big difference! :) And there would still be a big difference even if the later were somehow never touched again after the first "we are open-sourcing this!" commit.
That said, we do try to maintain the things we open-source. Standards of support vary because individuals maintaining these projects, and their situations, vary. This is true for non-OSS internal tools too. In my experience, having gone through the Uber OSS process twice, and having started it a third time and decided against releasing (yet?), Uber does try to make reasonably sure that it's open-sourcing stuff that will be useful and is planned to be maintained. At the same time, they have to balance it with making it easy to open-source tools, otherwise too many useful things would remain internal only.
Also, note, some of these tools have exactly one developer internally as the maintainer, and not even as their full time job. For example, I am the sole internal maintainer[1] for https://github.com/uber/NullAway and also have 3-4 other projects internally on my plate, most of which are in earlier stages and need more frequent attention[2]. If and when said developer leaves, effort is made to find a new owner. This is not always successful, particularly if the tool has become non-critical internally. Sometimes, leaving owners retain admin rights on the repos and keep working on the tool (Manu, NullAway's original author, co-maintains it), but I don't think anyone is suggesting that that should be an obligation.
Finally, obviously, nothing here is the official Uber position on anything, just my own personal observations. This doesn't represent my employer, and so on. I am also pretty sure most of this is not even Uber specific :)
[1] Not the only internal contributor! Also, there is one external maintainer, as mentioned a few sentences later. But in terms of this being anyone's actual responsibility...
[2] Just to clarify, I think between Manu's interest, my own, and it being relatively critical tooling at Uber, NullAway is pretty well maintained. But I can understand why that isn't always a given for all projects.
Disclaimer: I am a contributor to NullAway. There are plenty of other nullability static analysis tools for Java worth considering (Checker Framework, Eradicate, etc). NullAway's main strengths are a focus on performance and the idea that you should be able to use it as part of every (local) build of your code.