> Well, try to minimize the usage of nulls in your programs then :D
I am a java guy since 1.1 and it seems to me that a lot of problems in Java come down to it being designed for a time when a application mainly consisted of in-house / in-org / self-written code. In $currentYear, however, we mostly plug libraries into frameworks and it's just a pain to check every call and every return value for the possibilities of null. Yeah, it can be done but I just don't like having to read library source code to find out if it will return a null in some cases.
Open-source libraries were much less common when Java first arrived, but third-party C / Fortran libraries were very common in many domains much before Java arrived.
Nulls, arrays degenerating into pointers (losing size information), and accidentally crossing enum types across libraries were all huge sources of bugs. Java doesn't have much of an excuse for its treatment of nullability, other than they were trying to court C/C++ developers.
I don't have 100% control of my coworkers or library writers. Knowing whether a library or a coworker can hand me back an optional value seems like a pretty basic thing for a language to tell you
