How Project Valhalla And JSpecify Can Kill NPEs

[@prdoyle]

I'm glad they're being so careful about this. Also, Joda-time is a great example to follow.

[@lukeusherwood2525]

Very happy to hear Primitive classes were phased out - together with records and value (aka inline) types that would've been too many combinations. Whereas value-types and null-awareness: that sounds like an awesome combo!

[@lukeusherwood2525]

Also for libraries, I'd be v. happy to start using JSpecify in our own modules - I can see us going through one-by-one and formalising non-null unless marked @Nullable. We do that on all new code, but a standardized enforcement would be the motivation to finish the job and bring all the legacy code up to standard.

[@JohnX-tf7yf]

Hey, I'm glad to have come across your channel! Any chance you can make some videos to talk more about java in general? There are many amateur java developers who would really like to hear more explanatory coverage of java's features.

[@sitrilko]

I have to agree that a big part of the developer mental load can be taken up by not knowing what can or may be null. Coming from the Scala world where null p. much doesn't exist - instead you have Option[T]. And the mental benefit of not having to worry about a random NPE is one thing. Another major one is just having an easier time reasoning about your code logic once you clearly see which fields may or may not have a present value.

[@Art-kz6zf]

Are there any solid plans to start integrating Valhalla into JDK? I'm probably not the only one who has been reading JDK announcements for the past nine or so years waiting to see anything related to value objects in the release notes. Null-safety and value objects would be huge for Java.

[@redcrafterlppa303]

Why not make strict reference types null checks a compiler flag that has a long migration period. Like in a few years it's on by default and in another couple years it's permanent. And for lagacy libraries you could specify that they are excluded from the checks.

[@kevinb9n]

I would say that's the very general idea, but the devil's massively in the details. I personally would like to explore a concept similar to Rust's "editions" for marking a file as being in the new regime or old, but with Java everything is tricky.

[@redcrafterlppa303]

@@kevinb9n yeah, implementing library specific compilation with classfile compatibility now as an afterthought is something I would call impossible

[@juancarlospizarromendez3954]

null.equals(null) would yield true but won't work. My workaround could be creating a singleton object Nil for that Nil.equals(Nil) yields true. It's too control about the subject.

[@ebuzertahakanat]

value types should be not null-able as default and compiler should check for it

[@nipafx]

The problem with that approach is that some (many?) types that want to be value types need a signal value to indicate lack of initialization. For example a rational number with nominator and denominator would default to 0/0, which is a terrible default. Similarly, date times don't have a reasonable default and neither do values which are strictly positive. If they couldn't use null as a signal value if they are a value type, then they can't be value types and suddenly a big chunk of candidates can't use this new feature. In this conversation, we only briefly mentioned tearing, but that is a consideration, too. Would all value types have to accept tearing? Or would all value types pay the extra price to be protected from it?

[@ebuzertahakanat]

@@nipafx i don't know much about the subject but there are languages without null concept so i think those problems must be solvable maybe optional can be way to solve it. no pun intended

[@nipafx]

@@ebuzertahakanat Right, but other languages work differently and so do their VMs (if they even have one). Comparing languages to one another is fine but you can't infer that because something works well in one language it will work (well) in another. Also, I wouldn't open with "X should be done" when the follow-up is "I don't know much about the subject". 😉

[@ebuzertahakanat]

i didn't say should be done i said maybe, brain storming here @@nipafx we will see what they will do.

[@kevinb9n]

@@ebuzertahakanat I actually think that null when done right (Kotlin, modern Dart) is the superior approach!

[@MarcoServetto]

What about the interaction between null and generics?

[@kevinb9n]

How many hours do you have to spend? 🙂

[@kevinb9n]

part one: kzbin.info/www/bejne/foTCnHRqZ76Bobc