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

151–160 of 230 posts

Re: Retrofitting null-safety onto Java at Meta

#151

Post by ben7799 »

justin_oaks wrote: post #98
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 NullPoin…

The funny thing is these techniques were introduced in books like "Effective Java" before many of the developers who complain were even born.

Everyone should know these things by now. They are good things to ask about in interviews.

Re: Retrofitting null-safety onto Java at Meta

#152

Post by ender341341 »

krzyk wrote: post #144
ender341341 wrote: post #141

Earlier quoted context omitted.

But java has the worst of both worlds cause with an optional you now have 3 cases, Optional.empty, !Optional.empty, & null instead of just 2 cases. In our code base this means we have a the rule that Optional is only allowed for returns so we aren't adding 3rd cases all over the place.

I have never came up to a code that would pass null in place of Optional, why?

Because you don't always control where the code is being called from.

Other compile time typed languages (C, C++, C#, typescript, rust, kotlin) usually would let you enforce that as part of the type system, but the java compiler will silently accept null in place of optional and throw an NPE at runtime.

Re: Retrofitting null-safety onto Java at Meta

#153

Post by _old_dude_ »

islon wrote: post #110
BoorishBears wrote: post #99

Earlier quoted context omitted.

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…

I guess he's talking about project loom (fibers, go style concurrency) which IMHO is a much better solution than async/await, but yeah... took some 10 years to arrive.

During the last 10 years, the Java ecosystem has heavily invested in reactive APIs, so it's not like if Java devs have no option.

And IMO, the semantics of any reactive APIs is better than just providing await.

Await serializes the async calls instead of running them concurrently. And too few C# devs are aware of/using the Task API.

Re: Retrofitting null-safety onto Java at Meta

#154

Post by mohaine »

krzyk wrote: post #144
ender341341 wrote: post #141

Earlier quoted context omitted.

But java has the worst of both worlds cause with an optional you now have 3 cases, Optional.empty, !Optional.empty, & null instead of just 2 cases. In our code base this means we have a the rule that Optional is only allowed for returns so we aren't adding 3rd cases all over the place.

I have never came up to a code that would pass null in place of Optional, why?

Pretty much every JSON parser in java does this by default. Why? Because they were all written before Optional existed.

I have to agree with the Optional hate. I loved it in Scala but after a few months on Kotlin I don't think I can go back.

Re: Retrofitting null-safety onto Java at Meta

#155

Post by pron »

Retric wrote: post #137
pron wrote: post #113

Earlier quoted context omitted.

Increased productivity comes in various ways. A more popular language often has a better ecosystem that helps productivity, and adding lots of language features quickly is a hindrance to huge popularity. This might not be the case for many here, but most programmers prefer fewer features than more, and the most popular languages are also often those that can be taught as a first language, which also requires restrain…

I know vastly more programmers that have abandoned Java than swapped to it. That’s not to say it failed. Java is one of the most popular languages, but it does suggest real issues with the current approach.

And you could probably say the same for JavaScript and Python, that, together with Java, make up the current topmost tier of super-popular programming languages, which is why I think your conclusion is wrong.

These three languages are often first languages (or, at least, first professional languages), which is a necessary (though insufficient) condition for being super-popular. All of these languages more than make up for the loss of programmers who prefer richer languages with the programmers for whom it's a first (professional) language. Different programmers indeed prefer different languages, but that doesn't mean that the preferences are easily distributed. My rough personal estimate is a 90-10 split, where the 10% prefer more feature-rich, faster-moving languages. That's a very big minority, but Java addresses it by offering the Java language for the 90%, and supporting other languages on the Java platform for the 10%.

You can also see that while the market is becoming more fragmented, no language is currently threatening those top three (although TypeScript could threaten JS, I think), and no language is doing better than them. I.e. other strategies seem to be doing worse.

So knowing that for every X programmers you win you lose Y no matter what you do means that we try to carefully balance the evolution. I can tell you that we are more worried about teachers telling us that Java is getting too many features too quickly, and that it's harder to teach than Python (hence "Paving the Onramp [1] and other planned features) than the programmers asking for more features quicker. The former represent a much larger group than the latter. Also, moving more toward the latter group is both easier and less reversible, so it has to be done with great care.

[1]: https://openjdk.org/projects/amber/design-notes/on-ramp

Re: Retrofitting null-safety onto Java at Meta

#156

Post by simplotek »

hn_throwaway_99 wrote: post #117
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…

I have definitely come to the conclusion, especially after doing a lot of work in Typescript, that class Optional is a big mistake, whether from the JDK or other libraries that preceded it. First, because exactly the type of code that the parent commenter showed. I've actually seen this in production code (and shrieked). The fact is that without language-level support, you can end up getting the worst of all worlds.…

> But, most importantly, the fundamental issue is that all classes are optional by default in Java (indeed, that's the problem at hand). Adding an Optional class doesn't really mean you can make any non-nullability assumptions about other classes, especially when using different libraries.

Perhaps it's just me, but I don't equate optional with nullable. An optional value is just the designer specifying that you may or many not specify that value, while nullable are objects which may or may not have been initialized yet.

Even though nullables have been used and abused to represent optional values, I'm not sure it's a good idea to conflate both. It would be like in C++ equating shared pointers with optional types.

Re: Retrofitting null-safety onto Java at Meta

#157

Post by pharmakom »

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

Optional is not just another class. The control flow in the compiler will check that optionals are checked.

Re: Retrofitting null-safety onto Java at Meta

#158

Post by jimmaswell »

tehlike wrote: post #112
pron wrote: post #106

Earlier quoted context omitted.

First of all, Java's generics are already superior to C#'s. We've exchanged the minor inconvenience of not being able to have overloads that erase to the same type with the ability to support multiple variance strategies rather than one that's baked into the runtime. That's why Java has Clojure and Kotlin and Scala and Ruby running on top of it with such great interop. And, as it turns out, when specialisation is rea…

"Java generics is superior to C#" - That's a first for me. C# generics don't have to do boxing of types like java does, and overall have much better type safety between library boundaries, etc...

C# also declined to make the mistake of type erasure.

Re: Retrofitting null-safety onto Java at Meta

#159

Post by cogman10 »

hn_throwaway_99 wrote: post #117
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…

I have definitely come to the conclusion, especially after doing a lot of work in Typescript, that class Optional is a big mistake, whether from the JDK or other libraries that preceded it. First, because exactly the type of code that the parent commenter showed. I've actually seen this in production code (and shrieked). The fact is that without language-level support, you can end up getting the worst of all worlds.…

> But, most importantly, the fundamental issue is that all classes are optional by default in Java (indeed, that's the problem at hand). Adding an Optional class doesn't really mean you can make any non-nullability assumptions about other classes, especially when using different libraries. The Optional class just added more complexity while simplifying very little.

When pron mentioned "this is actively being worked on", he meant exactly this problem. [1] [2] Java is currently working on changing the dynamics of the language such that classes can in fact be non-nullable. Last I checked in, this was the notion of `primitive` types being added in project Valhalla.

Optional just so happens to be one of the types in the JDK that will converted over to being a `primitive` type.

Now, what that means in terms of existing code I believe what's being discussed. How do you handle

    public Optional bar() { return null; }
?

We'll see, it might be something like changing the code to something like this

    public Optional.val bar() { return Optional.empty(); }
which would guarantee that the optional type returned is in fact never null.

[1] https://github.com/openjdk/valhalla-docs/blob/main/site/desi...

[2] https://github.com/openjdk/valhalla-docs/blob/main/site/earl...

Re: Retrofitting null-safety onto Java at Meta

#160

Post by coding123 »

BoorishBears wrote: post #95
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…

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 bleed…

Every time this argument comes up I get a sudden urge to eat refried beans for some reason.
Post reply on HN