Hacker News Reader

Comment by ianpurton | Hacker News Reader

I'm curious if it would be possible to remove null from Java.

There's already support for Optional.

I mean I guess a lot of code would stop compiling, or could it be deprecated somehow.

Java tries so hard to be backwards compatible, I think null is here to stay. There is always Kotlin if you want better null safety, or compile time checks like null-away, but they are still null adjacent. Disappointing but that’s what we’re stuck with in service of backwards compatibility, but I’m not sure making these breaking changes is an improvement… look at Python 2->3 for an example

yes and most java developers have come to terms with null and NPE, it's just part of programming in Java so honestly I'm fine with it being here.

...and now that NPE has a "helpful" message, I've generally found it to be almost a non-issue these days. During development, I can usually figure out the problem immediately just from the message and I don't need to examine the stack trace.

I think it is certainly possible. In Scala you enable "explicit nulls" and it will not compile if you try to set a value to null (https://dotty.epfl.ch/docs/reference/other-new-features/expl...) without making the type a union with Null.

Not without changing everything in significant ways. There are two distinct kinds of types in Java: objects, including arrays, and primitives. Objects are represented as pointers, and those can be null — that's their default value. And multiple pointers can point to the same object. Primitives (int, long, boolean, char, byte, short, float, double) are "value types", they can't be null, are copied on assignment, and have meaningful default values (0 for numbers, false for booleans). Adding non-primitive value types would mean having to solve many new problems that C++ had and still has. That said, they are exploring this idea, iirc they call it "project valhalla".

Who said anything about non-primitive value types? Java just needs a second kind of reference type: non-nullable reference types that are always initialized, where a direct assignment from a nullable-reference-typed value to a non-nullable-reference-typed slot fails to compile (but the opposite succeeds.) You’d instead have to go through Optional.ofNullable or somesuch, where that proxy type would then be modified to have variants of .get et al that return a non-nullable-reference return type.

Java could adopt swift-like `Object!` typing for non-nullable variables and spread that guarantee through the compiler and JVM runtime.

I don't think it's a technical impossibility, but it's more likely to be solved by a JVM-based language like Kotlin than it is to get it adopted into the Java mothership.

Compile-time checks definitely can't guarantee anything. You could still end up with null pointers from, for example, a library like gson using reflection to set fields. If you add "non-null" to the type descriptors inside class files (something like Kjava/lang/Object; instead of the usual Ljava/lang/Object;) and have the JVM enforce non-null-ness at runtime, you'll still have crashes caused by null pointers but earlier. Oh and you'll have to make an exception to allow these to be null during a constructor or static initializer invocation so it could actually initialize everything. It gets messy.

IIRC that proposition for value types makes them more akin to structs, without inheritance and dynamic methods. And I don't remember whether the fields are final, but given the current trend towards making everything as immutable as possible, they probably are.

Why would "remove null" be better than the Dart approach — "When you opt into null safety, types in your code are non-nullable by default, meaning that variables can’t contain null unless you say they can." ?

https://dart.dev/null-safety

Maybe if Optional becomes a value type

Kotlin does it, but it's next to useless because the ecosystem makes heavy use of null.

what? I don't feel it's "pointless" at all. Many popular Java libraries and frameworks (including Spring) use nullability annotations which can be interpreted correctly by Kotlin. It's true that I can't be 100% sure not to get NPEs, but I think it's close enough and I've rarely seen NPEs in Kotlin codebases.

Indeed, Kotlin's null handling is great. NPE's in Kotlin code aren't common.

Kotlin is my suggestion too.

Kotlin (or any other JVM variant that does non-nullability in a seamless way) and coding guidelines should get you 90% of the way to a null-free world.

Reply on news.ycombinator.com