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

91–100 of 230 posts

Re: Retrofitting null-safety onto Java at Meta

#91

Post by cheriot »

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; }

Scala had the same possibility, but the ecosystem of libraries used Option appropriately so in practice I never thought about null. That might be harder in an older, larger ecosystem like Java...

Re: Retrofitting null-safety onto Java at Meta

#92

Post by pron »

pulse7 wrote: post #86

@Oracle: Please add this solution to the Java language and make Optional deprecated!

Why this solution? Maybe there's an even better solution? We're following the various experiments in the area, and when we have a solution we believe is the right one, we'll provide it, but not sooner than that.

Re: Retrofitting null-safety onto Java at Meta

#93

Post by jimbob45 »

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…

This area is under investigation, and when we have a solution we like, we'll implement it

What's to investigate? Just copy what C# did and be done with it.

Re: Retrofitting null-safety onto Java at Meta

#94

Post by dheera »

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'm not a Java person but isn't this just very similar to std::optional in C++?

https://en.cppreference.com/w/cpp/utility/optional

Re: Retrofitting null-safety onto Java at Meta

#95

Post by BoorishBears »

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…

It's like when people say Java had the chance to do generics right (like C#) and then didn't

Yeah technically tomorrow morning Java could fix it, but there have been kingdoms built on the current situation. C# took its lumps years back on breaking things and so there were fewer kingdoms to demolish. And if you fix it, it'll be years before it trickles down to a large portion of devs who don't get to work at the bleeding edge, or even near the edge.

Re: Retrofitting null-safety onto Java at Meta

#96

Post by 5e92cb50239222b »

jimbob45 wrote: post #93
pron wrote: post #31

Earlier quoted context omitted.

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…

This area is under investigation, and when we have a solution we like, we'll implement it What's to investigate? Just copy what C# did and be done with it.

Yeah, I've heard this kind of stuff in the past. "Just copy async/await from C#, what are you waiting for?". And now C# is stuck with that thing, while we'll soon be getting the proper solution.

Thanks, I'd rather wait.

Re: Retrofitting null-safety onto Java at Meta

#97

Post by rightbyte »

Traubenfuchs wrote: post #69

I have been writing Java for money for more than ten years and never ever have I had non-trivial problems with null. Less than one percent of the bugs I fixed were caused by nullpointers, less than one percent of write-deploy-test loops were caused by it. I either have code that can't be null (e.g. getters of lists that create a list if the field is null, outright validation before usage), code where null has a desir…

Null pointer exceptions are like free unit tests. The programmer assumed something never signaled an invalid result and was wrong.

I don't understand the fuss either. Logic problems from improper error handling is way worse than NPE.

Edit: Pointers that can be null actually are a sum type but without the fancy pants hype.

Re: Retrofitting null-safety onto Java at Meta

#98

Post by justin_oaks »

Traubenfuchs wrote: post #69

I have been writing Java for money for more than ten years and never ever have I had non-trivial problems with null. Less than one percent of the bugs I fixed were caused by nullpointers, less than one percent of write-deploy-test loops were caused by it. I either have code that can't be null (e.g. getters of lists that create a list if the field is null, outright validation before usage), code where null has a desir…

There are patterns that experienced developers will use to avoid issues with nulls. Here are a couple off the top of my head.

1) Reversing string comparisons:

    "literal".equals(variable)
instead of

    variable.equals("literal")
2) Always initializing lists instead of leaving them to default to null

   public class SomeClass{
      private List someList=new ArrayList(); //or Collections.emptyList()
      ...
   }
The problems with NullPointerExceptions can mostly be solved by teaching programmers to use these strategies and teaching them to look for boundaries where nulls can slip in.

The real problem happens when things get scaled up. If you have thousands of developers then it makes sense to take steps to automate the problem away. Also, if the code is used by billions of users then even rare NullPointerExceptions will happen frequently. So it makes perfect sense for Facebook to be the one to work on this.

Re: Retrofitting null-safety onto Java at Meta

#99

Post by BoorishBears »

5e92cb50239222b wrote: post #96
jimbob45 wrote: post #93

Earlier quoted context omitted.

This area is under investigation, and when we have a solution we like, we'll implement it What's to investigate? Just copy what C# did and be done with it.

Yeah, I've heard this kind of stuff in the past. "Just copy async/await from C#, what are you waiting for?". And now C# is stuck with that thing, while we'll soon be getting the proper solution. Thanks, I'd rather wait.

Can you point a couple of cases where Java got a better version?

Generics? Value Types? Lambdas? Null Safety? Async/Await?

Also do you just have to assign all the value the features provide in interim 0 value? Like Async/Await has provided a 10 years of value, and I'm guessing you mean Project Loom... so how much better than Async/Await does Loom have to be to justify an entire decade of just straight up missing the value add entirely, let alone having a better one

-

I can't reply to comments anymore (thanks dang) but yeah...

Generics at the Java layer are worse, generics at the JVM layer are convenient if you're going to write a language targeting the JVM. That's just an artifact of the fact that the JSR for Generics defined backwards compatibility as its top goals, not because they were trying to enable a friendlier runtime for languages that didn't exist yet.

I already addressed Project Loom: They're coming a decade after async/await are coming after a decade of a strictly worse concurrency story, so unless you're assigning 0 value to a decade of having a better situation (which I'd say is disingenous) I don't think it's a great example.

Also definitely not sure how Java Records are better than C#?

Re: Retrofitting null-safety onto Java at Meta

#100

Post by ahtihn »

Traubenfuchs wrote: post #69

I have been writing Java for money for more than ten years and never ever have I had non-trivial problems with null. Less than one percent of the bugs I fixed were caused by nullpointers, less than one percent of write-deploy-test loops were caused by it. I either have code that can't be null (e.g. getters of lists that create a list if the field is null, outright validation before usage), code where null has a desir…

> On the same note, I didn't understand the inclusion of Optional in Java.

It interacts nicely with stream pipelines.

Post reply on HN