top | item 40553199

(no title)

rcaught | 1 year ago

Appreciate Kotlin and others pushing it there.

discuss

order

The_Colonel|1 year ago

Unfortunately these pushers were not strong enough to get Java to add null-safety. "Everything can be null" is the by far biggest daily headache of working in Java codebases.

JSR-305, checker framework, Optional are all half-baked workarounds evidenced by the lack of their adoption.

wh0knows|1 year ago

If you properly handle not returning/using nulls in your checkstyle rules and don’t allow nulls to be deserialized anywhere (forcing the use of Optional), then you can pretty much eliminate NPE.

I can’t remember the last time I encountered one by using the proper compile time checks. It does need to be enforced organization-wide, and not partially with annotations, but if you can make that change then you can code in Java without the mental overhead of null.

kaba0|1 year ago

Yeah, the ant pushing the elephant..

marginalia_nu|1 year ago

Java's stated design philosophy since way back is to let other languages experiment and then incorporate what appears to work out, thus being able to maintain an append-only change philosophy where everything is always backwards compatible. Kotlin is undeniably a source of inspiration, as is many other languages.

(This doesn't always work out, some bad API decisions[1] will likely haunt Java forever, some features are arguably a bit undercooked (e.g. exception handling in Stream:s), but given the constraints it's kind of remarkable how well it does work)

[1] https://stackoverflow.com/questions/21410683/boolean-getbool...