Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Retrofitting null-safety onto Java at Meta

engineering.fb.com

Post reply on HN
Print view View original

41–50 of 230 posts

Re: Retrofitting null-safety onto Java at Meta

#41

Post by lowbloodsugar »

mrkeen wrote: post #32
sanedigital wrote: post #24

Earlier quoted context omitted.

Don't people use @NonNull everywhere now? It's been a few years since I've programmed in Java but even then I feel like that was common practice.

Yes, it's always been possible to check for nulls at runtime. Personally I use notNull(..) over @NonNull since it actually fires when you expect it to (as opposed to whether your framework dispatcher interceptor trigger decided to invoke it)

I think he means using @NonNull for compile time checking, not instrumenting it for runtime checking (though that doesn’t hurt either).

Re: Retrofitting null-safety onto Java at Meta

#42

Post by pron »

djinnandtonic wrote: post #3

Or use Kotlin, it's near perfectly interoperable with Java and the acclamation period is measured in weeks if you're a Java dev

But then you have to use Kotlin, which isn't just Java with nullability types, but a language with quite a different design philosophy, and a language that is increasingly at odds with the evolution of the JDK (partly but not solely because it also targets other platforms, such as Android and JS). It appeals to some but certainly not to all (interestingly, it hasn't significantly affected the portion of Java platform developers using alternative languages, which has remained pretty much constant at about 10% for the past 15 years).

Re: Retrofitting null-safety onto Java at Meta

#44

Post by modeless »

bagels wrote: post #30
driggs wrote: post #21

It's so sad that Java 8 had the chance to really fix the null problem, but gave us only the half-assed `java.util.Optional `. Rather than implementing optional values at the language level, it's just another class tossed into the JRE. This is perfectly legal code, where the optional wrapper itself is null: Optional getMiddleName() { return null; }

I love this solution. Now you have two kinds of nulls.

Just like JavaScript!

Re: Retrofitting null-safety onto Java at Meta

#45

Post by brabel »

We've been using `@Nullable` as Meta does in our code base for many years now (everything else is assumed to be non-null). Initially, we had CheckerFramework actually doing the checks at compile time... but eventually had to remove it because it's unstable, slow, has not kept up with Java evolution (we're on JDK 17, I think Checker still barely works on JDK 11) and also, because our IDE can be configured to flag errors on `probable nullability issue`! That was really a boon for us... it costs nothing at compile time and it's pretty easy to not mess up as the IDE keeps us in check whenever we make any change.

At the same time, we have adopted Kotlin as well. Interestingly, most of our developers prefer to stay on Java... not because they love Java, but because of familiarity and that they seem to think it's "good enough".

Anyway, we haven't had a large rate of NPEs for a very long time and when one actually happens in the wild we're extremely surprised!

That said: looking forward to the specification[1] that's being cooked up as Java absolutely should have had this a long time ago (as mentioned in the post).

[1] https://jspecify.dev/docs/start-here

Re: Retrofitting null-safety onto Java at Meta

#46

Post by [deleted] »

pron wrote: post #31
driggs wrote: post #21

It's so sad that Java 8 had the chance to really fix the null problem, but gave us only the half-assed `java.util.Optional `. Rather than implementing optional values at the language level, it's just another class tossed into the JRE. This is perfectly legal code, where the optional wrapper itself is null: Optional getMiddleName() { return null; }

What do you mean by had a chance? That chance isn't gone. This area is under investigation, and when we have a solution we like, we'll implement it. We can't address all issues at once. Optional isn't half-assed because it was never envisioned as a general solution to the null problem. It's simply an interface that's useful in streams and other similar cases for method return values, and it does the job it was intend…

[deleted]

Re: Retrofitting null-safety onto Java at Meta

#47

Post by jgavris »

djinnandtonic wrote: post #3

Or use Kotlin, it's near perfectly interoperable with Java and the acclamation period is measured in weeks if you're a Java dev

Migrating from Java to Kotlin looks nice and easy on the surface (optionals!), but the lack of checked exceptions will absolutely bite you sooner or later if you are consuming Java code. Better carefully read the docs and source of all your transitive Java dependencies.

Re: Retrofitting null-safety onto Java at Meta

#48

Post by zasdffaa »

pjc50 wrote: post #4

Related work: https://devblogs.microsoft.com/dotnet/nullable-reference-typ... C# has made it possible to gradually roll out stricter nullability checking as well. The static analysis gets integrated into the regular language analyzers. Incremental migration is the only way to go.

Some rare nice words from me about C# - the not-null facility is great. It's very basic propagation that should be better and I've fought the compiler too many times over it, but I really like the compile time guarantee it gives.

Re: Retrofitting null-safety onto Java at Meta

#49

Post by java_expert_123 »

exabrial wrote: post #18

This is just covering up design problems. NPEs show you were you have design deficiencies. If you have getAccount().getContact().getPhoneNumber() and contact is null, you'll get an NPE. The question shouldn't be: "How do I shove the NPE under the rug for the next 1337 coder to deal with?", the question should be: "How did I initialize an Account without a Contact?"

No it doesn't, it just forces these designs to be apparent at compile type and fail there instead of blowing up at runtime.

Do you not know why Kotlin exists or why dart added null safety or why C# added null safety? Or were they also wrong in their choices?

Re: Retrofitting null-safety onto Java at Meta

#50

Post by howinteresting »

twawaaay wrote: post #15
revskill wrote: post #8

OK, then i realize GoF design patterns lack the single most important pattern: Option data structure.

Nobody ever claimed that GoF is a complete set of patterns. It is just a subset of patterns from infinite variety of possible solutions to problems.

A very good argument is that the GoF stuff should be looked at with suspicion because they didn't bother nailing down the fundamentals.
Post reply on HN