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

121–130 of 230 posts

Re: Retrofitting null-safety onto Java at Meta

#121

Post by Larrikin »

sedro wrote: post #19
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

Kotlin interops nicely with Java but it's not null-safe (all references from Java are assumed non-null).

That is wrong all, non annotated Java code gets a special type denoted with a ! . You can use ?. or assign it to a new val with ?: return.

Or you throw all the null safety away and write unsafe java code but in Kotlin the same as the Java code you're working with.

Re: Retrofitting null-safety onto Java at Meta

#122

Post by travisd »

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…

I also hate this about Go, but its (partial) saving grace here is the `x, err := NewX()` pattern which (at least for me) tends to prevent a decent number of these issues in practice since usually either `x` is non-nil xor `err` is non-nil.

Makes the

    // Java
    name = personService.getPerson(123).getName()
problem less likely since you'd generally have to write:

    // Go
    person, err := personService.GetPerson(123)
    if err != nil { ... }
    name, err := person.Name()
    if err != nil { ... }
Definitely more verbose than maybe

    // TypeScript
    personService.getPerson(123)?.getName()
but I think that's part of Go's tradeoffs -- much more likely that errors will be annotated more correctly (i.e., in Go you'd be more likely return an error like "failed to load person: 123" if it was the GetPerson call that failed rather than a generic error that doesn't describe which step failed)

Re: Retrofitting null-safety onto Java at Meta

#123

Post by rad_gruchalski »

didip wrote: post #63
rad_gruchalski wrote: post #52

Earlier quoted context omitted.

Other jvm languages compile to the byte code and fix this by inlining the optional transparently. What you mean by “at a language level” would break the byte code for jars compiled with older jdks.

Breaking backward compatibility is not the end of the world.

Maybe not for you. I have experienced the Python 2 to 3. When I use Java, I’m happy I can rely on the compatibility.

Re: Retrofitting null-safety onto Java at Meta

#124

Post by masklinn »

mbfg wrote: post #116

I always wondered why enums in java were allowed to be null. Seemed like something they could have enforced. Could have just had some sort of 'default' attribute on a value.

> I always wondered why enums in java were allowed to be null.

Because they’re just the “type-safe enum” pattern, built in, with some compiler support (e.g. switches). Besides that they’re normal reference types.

> Could have just had some sort of 'default' attribute on a value.

Universal defaults are, if anything, even worse than universal nulls: they generate garbage states you can’t guard against at all.

Re: Retrofitting null-safety onto Java at Meta

#125

Post by pjmlp »

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...

The guys from Scala.NET did mention .NET generics as one of the reasons they gave up on porting Scala to .NET.

That is also a reason why .NET needed the whole effort to create DLR and the dynamic keyword, while Java only needed to add one additional bytecode invokedynamic.

Re: Retrofitting null-safety onto Java at Meta

#126

Post by Arbortheus »

brundolf wrote: post #37
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

I agree about Go. One quite frustrating scenario I have ran into multiple times is if you unmarshal (parse) some JSON into a struct, you can’t tell if an integer field with value 0 was specified in the JSON input as 0, or missing from the input. AKA there’s no way to differentiate the zero value from undefined for primitives.

There are roundabout hacky ways like parsing the JSON into a map[string]any to check if it’s there, but it’s so ugly and requires so many lines of code.

Re: Retrofitting null-safety onto Java at Meta

#127

Post by pjmlp »

coin wrote: post #101
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…

> cough Go cough Go is an old style language developed and released in modern times

Very old, given the time it has taken to catch up with CLU.

Re: Retrofitting null-safety onto Java at Meta

#128

Post by pjmlp »

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.

And we are still not using it, due to the pile of code out there.

Lets not forget the whole drama with prefix ! planned for .NET 7.

Re: Retrofitting null-safety onto Java at Meta

#130

Post by pjmlp »

twawaaay wrote: post #59
jerf wrote: post #55

Earlier quoted context omitted.

Nobody should have ever claimed the GoF is a complete set of patterns. The GoF themselves vigorously said it was not intended to be. But it has definitely been raised up to The Official Set Of Design Patterns by a lot of people. I've lost count of the number of languages I've seen someone write about "design patterns" in, and what they mean is they show a complete ported implementation of all the GoF design patterns,…

It is the same old story, later repeated with agile manifesto, REST, and so on. They became misunderstood and abused by enough people that the terms stopped meaning anything useful in public space. When I hear a company say "we're Agile, we are doing REST" etc. I just roll my eyes and think to myself: unlikely. Over the years I figured out the right way to use all of these things: as resources with solutions to frequ…

One interesting point is how many think there is Java code on GoF.
Post reply on HN