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

Retrofitting null-safety onto Java at Meta

engineering.fb.com

Post reply on HN
Print view View original

51–60 of 230 posts

Re: Retrofitting null-safety onto Java at Meta

#51

Post by colejohnson66 »

commandlinefan wrote: post #36
exabrial wrote: post #18

This is just covering up design problems. NPEs show you were you have design deficiencies. If you have getAccount().getContact().getPhoneNumber() and contact is null, you'll get an NPE. The question shouldn't be: "How do I shove the NPE under the rug for the next 1337 coder to deal with?", the question should be: "How did I initialize an Account without a Contact?"

> getAccount().getContact().getPhoneNumber() Every time I see people "deal" with this problem, it looks like this: if (getAccount() != null && getAccount().getContact() != null && getAccount().getContact.getPhoneNumber() != null) { // do something } // don't put an else condition in, just keep going and let the program // produce the wrong result in a confusing way when it happens in production I actually blame rampa…

With that awful `if` statement, you're calling the functions multiple times. It's negligible with the simple getters Java users use everywhere, but if that `getAccount()` call involved, say, the database, now you're making multiple calls when you don't have to.

C# at least has null propagation and pattern matching that can make that line:

    if (getAccount()?.getContact()?.getPhoneNumber() is string pn) {
        // do something with `pn`
    }
The "idiomatic" C# way would also include properties:

    if (GetAccount()?.Contact?.PhoneNumber is string pn) {
        // do something with `pn`
    }

Re: Retrofitting null-safety onto Java at Meta

#52

Post by rad_gruchalski »

didip wrote: post #43

Java has so many deficiencies in its design that so many frameworks are invented to cover its flaws. Just give a real Optional type at a language level. It’s clearly possible in other JVM languages.

Other jvm languages compile to the byte code and fix this by inlining the optional transparently.

What you mean by “at a language level” would break the byte code for jars compiled with older jdks.

Re: Retrofitting null-safety onto Java at Meta

#53

Post by adra »

yamtaddle wrote: post #12
iLoveOncall wrote: post #7

Earlier quoted context omitted.

I can't think of any popular language that would take more than a few days to get acclimated to as an experienced developer, so that's not a very compelling argument.

It's always the (usually quite bad) tooling, learning about platform/SDK shittiness and pitfalls, and figuring out which parts of the open-source library ecosystem you want to engage with, that takes like 90+% of the time getting decent with a new language, in my experience. Getting comfortable with the language per se takes low tens of hours at most, as you wrote.

Kotlin (the base language) is really not that different from java. I went from 0 to standing up new backend services with limited friction. Coroutines and maybe frontends are a different story. Java doesn't yet have a coroutines equiv so that was a larger hurdle for me.

Most of the changes for me from 10/20+ hours to now we're more about identifying a style that works as effectively as I can. These types of behaviours are normal in all but the most idiomatic languages, so if anyone is doing java dev as their daily language, Kotlin felt very natural(though you really are limited to Intellij since the IDE does a ton of lifting to make your life easy).

Re: Retrofitting null-safety onto Java at Meta

#54

Post by twawaaay »

howinteresting wrote: post #50
twawaaay wrote: post #15

Earlier quoted context omitted.

Nobody ever claimed that GoF is a complete set of patterns. It is just a subset of patterns from infinite variety of possible solutions to problems.

A very good argument is that the GoF stuff should be looked at with suspicion because they didn't bother nailing down the fundamentals.

I actually have the fricking book on my bookshelf. The first paragraph on the first page of the book starts:

"This book isn't an introduction to object-oriented technology or design. Many books already do a good job of that. This book assumes you are reasonably proficient in at least one object-oriented programming language, and you should have some experience in object-oriented design as well."

At no point it claims to be any kind of software development handbook or complete set of patterns or teaching fundamentals of anything. It is just a collection of "hey guys, see, we figured out this might be useful for ya!".

Re: Retrofitting null-safety onto Java at Meta

#55

Post by jerf »

twawaaay wrote: post #15
revskill wrote: post #8

OK, then i realize GoF design patterns lack the single most important pattern: Option data structure.

Nobody ever claimed that GoF is a complete set of patterns. It is just a subset of patterns from infinite variety of possible solutions to problems.

Nobody should have ever claimed the GoF is a complete set of patterns. The GoF themselves vigorously said it was not intended to be.

But it has definitely been raised up to The Official Set Of Design Patterns by a lot of people. I've lost count of the number of languages I've seen someone write about "design patterns" in, and what they mean is they show a complete ported implementation of all the GoF design patterns, including all OO quirks, even in languages where they are manifestly inappropriate, including dynamically typed languages (where many of them apply, but are optimally designed quite differently to account for the huge differences in the type system) and functional languages (when many of the GoF patterns just dissolve into the language, but a whole other set of patterns is necessary).

Re: Retrofitting null-safety onto Java at Meta

#56

Post by godshatter »

exabrial wrote: post #18

This is just covering up design problems. NPEs show you were you have design deficiencies. If you have getAccount().getContact().getPhoneNumber() and contact is null, you'll get an NPE. The question shouldn't be: "How do I shove the NPE under the rug for the next 1337 coder to deal with?", the question should be: "How did I initialize an Account without a Contact?"

An aside here, but wouldn't it be simpler to eschew the syntactic sugar and get the account first and then if it's not null then get the contact and if it's not null then get the phone number and return it, returning null if any of those conditions fail? Then there's no exception to handle and flow is not broken.

A null phone number would indicate one wasn't found, which could mean the contact record didn't have one, the account didn't have a contact record, or there was no account. If this violates a business rule, then throw a MissingAccount or MissingContact or MissingPhoneNumber exception at the appropriate place that would be more understandable to the end user or could be handled more specifically than a generic null pointer exception.

I'm a C programmer, though, so I'm used to taking the long way around to do things, usually because there's no other choice.

Re: Retrofitting null-safety onto Java at Meta

#57

Post by dehrmann »

driggs wrote: post #21

It's so sad that Java 8 had the chance to really fix the null problem, but gave us only the half-assed `java.util.Optional `. Rather than implementing optional values at the language level, it's just another class tossed into the JRE. This is perfectly legal code, where the optional wrapper itself is null: Optional getMiddleName() { return null; }

I wonder if the plan is to add syntactic sugar for Optional in a future version.

Re: Retrofitting null-safety onto Java at Meta

#58

Post by return_to_monke »

commandlinefan wrote: post #36
exabrial wrote: post #18

This is just covering up design problems. NPEs show you were you have design deficiencies. If you have getAccount().getContact().getPhoneNumber() and contact is null, you'll get an NPE. The question shouldn't be: "How do I shove the NPE under the rug for the next 1337 coder to deal with?", the question should be: "How did I initialize an Account without a Contact?"

> getAccount().getContact().getPhoneNumber() Every time I see people "deal" with this problem, it looks like this: if (getAccount() != null && getAccount().getContact() != null && getAccount().getContact.getPhoneNumber() != null) { // do something } // don't put an else condition in, just keep going and let the program // produce the wrong result in a confusing way when it happens in production I actually blame rampa…

Surprised that guard clauses weren't mentioned here yet, you could also write

``` if (account == null) { throw NoAccountException }

if (account.contact == null) { throw AccountWithoutContactException }

if (account.contact.phoneNumber == null) { throw ContactWithoutPhoneNumberException }

// do stuff here ```

Re: Retrofitting null-safety onto Java at Meta

#59

Post by twawaaay »

jerf wrote: post #55
twawaaay wrote: post #15

Earlier quoted context omitted.

Nobody ever claimed that GoF is a complete set of patterns. It is just a subset of patterns from infinite variety of possible solutions to problems.

Nobody should have ever claimed the GoF is a complete set of patterns. The GoF themselves vigorously said it was not intended to be. But it has definitely been raised up to The Official Set Of Design Patterns by a lot of people. I've lost count of the number of languages I've seen someone write about "design patterns" in, and what they mean is they show a complete ported implementation of all the GoF design patterns,…

It is the same old story, later repeated with agile manifesto, REST, and so on.

They became misunderstood and abused by enough people that the terms stopped meaning anything useful in public space. When I hear a company say "we're Agile, we are doing REST" etc. I just roll my eyes and think to myself: unlikely.

Over the years I figured out the right way to use all of these things: as resources with solutions to frequent problems.

So no, I will not preach GoF or DDD or CQRS or Agile or REST or anything else, but I will make sure I understood each one very well on many levels and apply the lessons to my projects.

Re: Retrofitting null-safety onto Java at Meta

#60

Post by AtNightWeCode »

pjc50 wrote: post #4

Related work: https://devblogs.microsoft.com/dotnet/nullable-reference-typ... C# has made it possible to gradually roll out stricter nullability checking as well. The static analysis gets integrated into the regular language analyzers. Incremental migration is the only way to go.

C# have taking it further. New projects give errors if you don't declare vars as nullable when they may be null in some context. It will help for static analyzers to find these cases. I see a big risk in it. That people will just init nonsense objects to get around the warnings.
Post reply on HN