Hacker News Reader

Comment by arein3 | Hacker News Reader

Project Valhalla will go into Java 28 (next year, and preview version).

Fingers crossed I'll manage to use null type safety in my lifetime.

> Project Valhalla will go into Java 28

Unfortunatley without specialized generics and without the performance benefits that are supposed to come with it. They were too slow with Valhalla.

universal null type safety has sadly been discarded as a core concept of Valhalla in my Understanding; that being said, the proposals in Valhalla have null-safety as a side effect, but only under certain conditions.

When (if) null safety ships, I‘m not sure I can justify using Kotlin any longer.

Java simply got too nice.

Multiplatform and Compose come to mind as Kotlin differentiators. I agree rest of the language actually slowly falls behind

Falls behind how? Isn't it still ahead? Kotlin keeps changing too, you know!

Really? I don't thinks so. There is a reason JEP 539 is in preview. There is a reason internal annotations exists in current valhalla jdk prototype and upcoming java 28 such as @jdk.internal.vm.annotation.NullRestricted, @jdk.internal.value.ValueClass.newNullRestrictedNonAtomicArray. Also, there is a reason value classes are allowed to be null. This is because nullness types will be a key factor to the java language.

You really need to dare to try something else, Kotlin has been available for many years and the cost for a Java shop is super small since the same tools work with both. I’ve used also Dart which is lots of fun. Even Typescript can be a good alternative depending on what you’re doing. All have nullability guarantees and a nicer type system than Java while being in the same ballpark in terms of performance.

NullAway with JSpecify annotations are a really good way to add null safety to Java applications. Even enforces nullability at the generic level.

The elephant in the room is the standard library (collections). It isn't even type safe yet, because some methods were around before generics were added. And collections are too core for anyone to be able to agree on a 3rd party standard.

I mean, I guess you could say stuff like get(Object) and contains(Object) aren't type safe, but I've never seen that as an issue in practice. Plus there are some ErrorProne checks that'll tell you if you're doing something wrong in regards to calling contains(Object) with the wrong type.

They accept Object not because they're not type safe. They accept Object because key `equals` method might return `true` for unrelated classes by design, and collections interfaces have to accommodate for that. In other words, you might put key of class C1 into the map, and later use `get` with key of class C2. And if these classes happen to implement `equals` accepting each other, the collections are supposed to work.

So the core issue is that `Object.equals` method isn't type safe. Collections API just follow that.

A first step of Valhalla that is ...

Reply on news.ycombinator.com