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

31–40 of 230 posts

Re: Retrofitting null-safety onto Java at Meta

#31

Post by pron »

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 intended to do reasonably well. It's possible that a solution to nulls in the type system could have obviated the need for Optional, but I don't think that delaying lambdas and streams until such a solution was found would have been a better decision.

Re: Retrofitting null-safety onto Java at Meta

#32

Post by mrkeen »

sanedigital wrote: post #24
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; }

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)

Re: Retrofitting null-safety onto Java at Meta

#33

Post by BoorishBears »

sanedigital wrote: post #24
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; }

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.

In my experience mostly people forced to use Java who are then consuming said code in Kotlin do that

Re: Retrofitting null-safety onto Java at Meta

#34

Post by BoorishBears »

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)

Do the heuristics used for Kotlin-interop work with notNull(...)?

Re: Retrofitting null-safety onto Java at Meta

#35

Post by lesuorac »

pjc50 wrote: post #5
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

As they point out, they already have some Kotlin and use it interoperably, but "rewrite existing code in Kotlin" is not a realistic demand.

IIUC, there's already automated tooling that will do the conversion and not produce a giant mess like c/c++ to rust does so the cost is predominately CPU and not SWE.

Re: Retrofitting null-safety onto Java at Meta

#36

Post by commandlinefan »

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?"

> getAccount().getContact().getPhoneNumber()

Every time I see people "deal" with this problem, it looks like this:

    if (getAccount() != null &&
        getAccount().getContact() != null &&
        getAccount().getContact.getPhoneNumber() != null)  {
       // do something
    }
    // don't put an else condition in, just keep going and let the program
    // produce the wrong result in a confusing way when it happens in production
I actually blame rampant code generation and an adamant refusal to even consider object-oriented design for this problem - this sort of case ought to be handled by something like:

    getAccount().callContact()
(or whatever you were going to do with the phone number when you got it). Insistence on generating code from SQL schemas or XML DTDs and then writing procedural code makes that pretty much impossible, though.

Re: Retrofitting null-safety onto Java at Meta

#37

Post by brundolf »

justin_oaks wrote: post #11

The null problem has been around a very long time. It's been a huge source of errors in programming. I'm glad to see it actively being worked on, even if it is awkwardly being retrofitted on an old language. I can only look on with disappointment when new (or newish) languages include null as part of the language instead of doing something more sensible like having an Option/Either type. Of course, I won't name names…

It's okay for null to be a part of the language as long as the type system can reason about it (via nullable-types, sum types, etc). Dart, TypeScript, Kotlin are examples. But yeah, Go is the problem-child that doesn't have any way of statically reasoning about nulls

Re: Retrofitting null-safety onto Java at Meta

#38

Post by commandlinefan »

chrisseaton wrote: post #25
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?"

> the question should be: "How did I initialize an Account without a Contact?" Well yeah that's exactly what static analysis can tell you - what code path led to that. You're saying this project should be what it already is.

> How did I initialize an Account without a Contact

Actually I already know - he got it from a JSON feed from an external system and ran that JSON through an automated code generator.

Re: Retrofitting null-safety onto Java at Meta

#39

Post by Thaxll »

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?"

There are other problems such a null vs empty string in the database for example.

Once you start dealing with API + conversion + db, if your language exposse null, it will be painful.

Re: Retrofitting null-safety onto Java at Meta

#40

Post by melling »

sanedigital wrote: post #24
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; }

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.

“Unannotated types are considered not-nullable”

Defaulting to not-nullable is a great idea. Much less boilerplate.

Post reply on HN