I mean... the type checker is a static analyzer. Why not bake the most commonly seen type error into the language's type checker?

For all of its flaws, at least C++ made null references undefined behavior. Coming from (pre-NotNull) Java, it's nice to avoid lots of defensive null-check boilerplate.

Static analysis can go only so far. The Intellij has been helpful, but far from sufficient. One of the fundamental problems is also that static analysis won't help you differentiate between an intent (the method should not return null) and a mistake (it returns null anyway).

@NotNull/@Nullable is not part of the standard lib, but is a de facto standard nonetheless. I found that defaulting to everything non-nullable (there is a setting in these tools which should be the default, implicit nullable or non-nullable) and providing the few places where you want to use null explicitly gives you effectively the same null safety as Kotlin (note that the standard lib is annotated by these tools)

> @NotNull/@Nullable is not part of the standard lib, but is a de facto standard nonetheless.

Which one is the standard, the dormant JSR-305, the IntelliJ annotations or the checker framework (I guess that's the best candidate since it was actually accepted)?

> I found that defaulting to everything non-nullable (there is a setting in these tools which should be the default, implicit nullable or non-nullable)

Does this have a good cross-IDE support?

> gives you effectively the same null safety as Kotlin

"effectively", just ergonomically way worse.

But the main issue I have with this is that it requires you to actively seek null safety, pick a particular "standard" and push it through, ruthlessly enforce it during a code review. Which mostly doesn't happen. I've never seen a large codebase (which I would work on) which would use such annotations consistently. Yet unsurprisingly, all Kotlin code bases I've seen were in fact null safe.

> Which one is the standard, the dormant JSR-305, the IntelliJ annotations or the checker framework (I guess that's the best candidate since it was actually accepted)?

Hence “de facto”. All of these tools understand all of them.

And I do have to agree with your last paragraph, it is not as good as native support, but nor is it as big of a pain point as it used to be/as some people think it still is.

> but nor is it as big of a pain point as it used to be/as some people think it still is.

It's a big enough pain point that I resigned myself on null-safety in existing Java projects.

I rarely have the opportunity to start projects from scratch, and for those I'd rather use Kotlin.

> I found that defaulting to everything non-nullable (there is a setting in these tools which should be the default, implicit nullable or non-nullable) and providing the few places where you want to use null explicitly gives you effectively the same null safety as Kotlin

Not really, I'd say not even close. In Java you would be trying to avoid nulls whenever possible, but in Kotlin nulls elegantly become a flow control feature.

Yes, but the ergonomics of working with nullable data in Java are generally bad, and you have to do it everywhere

Well, try to minimize the usage of nulls in your programs then :D

For mappings between objects’ deeply nested properties I found mapstruct to be the best tool which will handle it correctly either way.

> 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