Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What if null was an Object in Java?

donraab.medium.com

Post reply on HN
Print view View original

51–60 of 164 posts

Re: What if null was an Object in Java?

#51

Post by coin »

jflwyasdf wrote: post #23
alkonaut wrote: post #21

Earlier quoted context omitted.

A null collection and an empty collection are two different things. A nullable collection is one that has the state “no collection” semantically separate from “empty collection”. Similarly an Option has 257 different values while a byte has 256 different values. That the byte has a good zero value doesn’t change that - the whole reason for choosing a maybe-byte is having 257 values, not 256.

Right that depends if you subscribe to the belief that null means the absence of a value `Option ` or does it mean the zero value `T`.

Null is the absence of a value. How do to distinguish 0 from no value?

Re: What if null was an Object in Java?

#52

Post by erik_seaberg »

jflwyasdf wrote: post #9
hedora wrote: post #8

Earlier quoted context omitted.

An Optional is just a tri-valued null (null, None, and Some), so no. It'd be nice if Java had a concept of a never-null reference (like a C++ reference vs. a C++ pointer), but the @NotNull annotation wasn't enforced the last time I checked. Also, there's no way for an object to express that invariant because encapsulation is so weak. Given only this constructor (and no reflection): Foo() { foo.bar = new Bar(); /* foo…

Fortunately, Uber made tooling for languages with broken type systems * https://github.com/uber/NullAway * https://github.com/uber-go/nilaway

Lombok, Error Prone, and Kotlin also have their takes on the problem.

Re: What if null was an Object in Java?

#55

Post by nitwit005 »

It'd be fairly easy to modify Java so that the primitives, including null, behave more like objects. And certainly, Java has inched that direction.

It doesn't solve anything fundamental though. You could make null.toString() return "null", but in most cases that will just be a bug. You're missing a null check or failed to initialize something.

Re: What if null was an Object in Java?

#56

Post by mrkeen »

alkonaut wrote: post #24
hedora wrote: post #8

Earlier quoted context omitted.

An Optional is just a tri-valued null (null, None, and Some), so no. It'd be nice if Java had a concept of a never-null reference (like a C++ reference vs. a C++ pointer), but the @NotNull annotation wasn't enforced the last time I checked. Also, there's no way for an object to express that invariant because encapsulation is so weak. Given only this constructor (and no reflection): Foo() { foo.bar = new Bar(); /* foo…

Wait, javas Optional is a reference type so it can be null? Doesn’t that almost defeat the purpose of it?

It gives you the ability to treat nulls as something-to-fix.

In a team without Optionals, every time you touch a null that you didn't expect, you have to decide "Is this deliberately null, or was it a mistake?" Without that knowledge, you don't know whether your code should assert against the null, or allow it to pass through as a valid value.

With Optionals, it becomes much simpler to cut through that nonsense. A null is a bug and you fix it (with the exception of json at the boundaries of your system, etc.) If you do find a value where you change your mind about its nullability, changing it to/from Optional will give you compile errors in exactly those other parts of the code that you now have to check/change.

Re: What if null was an Object in Java?

#57

Post by jeroenhd »

m_fayer wrote: post #7

I think the nullable reference type system in c# is a perfectly workable compromise for languages that had nullability from the very beginning. Once a code base uses them fully, most null-related bugs are gone. And it’s far from an unwieldy bolt-on.

With a good IDE configured to break on nullability errors, @Nonnull and @Nullable can also be used to replace the C# system in practice (not the same, but close enough). Unfortunately, this requires coordination from different team members and external dependencies rather than standard language features.

Re: What if null was an Object in Java?

#58

Post by sedro »

hedora wrote: post #8
randomopining wrote: post #3

Doesn't an Optional basically cover this case

An Optional is just a tri-valued null (null, None, and Some), so no. It'd be nice if Java had a concept of a never-null reference (like a C++ reference vs. a C++ pointer), but the @NotNull annotation wasn't enforced the last time I checked. Also, there's no way for an object to express that invariant because encapsulation is so weak. Given only this constructor (and no reflection): Foo() { foo.bar = new Bar(); /* foo…

> I can't think of another statically typed language that screws this up so badly. It just keeps getting worse with stuff like Optional and @NotNull.

Java might be the only language where a simple assignment `x = y` can throw a NullPointerException (due to auto-unboxing)

Re: What if null was an Object in Java?

#59

Post by Maxatar »

tsimionescu wrote: post #46
hedora wrote: post #25

Earlier quoted context omitted.

Doing it requires two threads. Thread A sets a shared reference to a newly allocated and null initialized reference to Foo: shared = new Foo(); While that's running, thread B invokes a method on the reference that assumes bar is non-null: shared.useBar(); // null pointer exception Later, thread A runs the constructor for Foo.

By that standard, C and C++ are much worse, since they offer no runtime encapsulation at all, and have much worse and more subtle multithreaded errors (e.g. Java at least guarantees that all native word sized reads/writes are atomic, if I recall correctly). C++ doesn't even guarantee that a reference can't be null, or worse, deallocated before it is dereferenced. They allow you to specify that a field is of some type…

We can quibble on definitions here, but a reference in C++ can not be null. The undefined behavior happens before any assignment to a reference is executed so that at the moment that the assignment happens, the reference is guaranteed to not be null.

In your example, it's the dereference of the pointer to p that is undefined behavior, so anything that happens after that point is also undefined behavior. Note that means there is never an actual assignment to r if p is null.

As I mentioned earlier, this might seem like quibbling with definitions, but this is the proper mental model to have with respect to C++'s semantics.

Having said that, I don't disagree with the main crux of your point, which is that C++'s semantics are terrible and there is little that the language provides to write correct code, but I do think there are subtleties on this matter that are worth clarifying.

Re: What if null was an Object in Java?

#60

Post by equalsione »

Larrikin wrote: post #19
philipwhiuk wrote: post #4

I don't actually think it solves any problems. You still have to null check.

Null should be valid. Kotlin solved Java's problem by making it a compiler error if a value that can be null isn't checked and shown to be null or the actual value, eliminating an entire class of exceptions.

I’m not familiar enough with kotlin to comment fully but from your description the checker framework [0] appears to do the same thing in Java.

I confess I’m not fond of checker framework. I find the error messages can be obtuse but it is very effective.

0 - https://checkerframework.org/

Post reply on HN