Meme transcription: Panel 1. Two images of JSON, one is the empty object, one is an object in which the key name maps to the value null. Caption: “Corporate needs you to find the difference between this picture and this picture”
Panel 2. The Java backend dev answers, “They’re the same picture.”
You must log in or register to comment.
If you’re branching logic due to the existence or non-existence of a field rather than the value of a field (or treating undefined different from null), I’m going to say you’re the one doing something wrong, not the Java dev.
These two things SHOULD be treated the same by anybody in most cases, with the possible exception of rejecting the later due to schema mismatch (i.e. when a “name” field should never be defined, regardless of the value).
Ya, having null semantics is one thing, but having different null and absent/undefined semantics just seems like a bad idea.
Not really, if absent means “no change”, present means “update” and null means “delete” the three values are perfectly well defined.
For what it’s worth, Amazon and Microsoft do it like this in their IoT offerings.
Thanks for the transcription!
Surely Java can tell the difference between a key with a null value and the absence of that key, no?
I mean, you can set up your deserialization to handle nulls in different ways, but a string to object dictionary would capture this, right?
Sure, Java can tell the difference. But that doesn’t mean that the guy writing the API cares whether or not he adds a key to the dictionary before yeeting it to the client.
Kinda, I guess we all can agree it’s more typical to deserialize into POJO where theres is no such thing as missing field. Otherwise why would you choose Java if you don’t use types. This great precondition for various stupid hacks to achieve „patching” resources, like blank strings or negative numbers for positive-only fields or even Optional as a field.
It can, but especially during serialization Java sometimes adds null references to null values.
That’s usually a mistake by the API designer and/or Java dev, but happens pretty often.
That’s the thing though, isn’t it? The devs on either side are entering into a contract (the API) that addresses this issue, even if by omission. Whoever breaks the contract must rightfully be ejected into the stratosphere.
That’s exactly not the thing, because nobody broke the contract, they simply interpret it differently in details.
Having a null reference is perfectly valid json, as long as it’s not explicitly prohibited. Null just says “nothing in here” and that’s exactly what an omission also communicates.
The difference is just whether you treat implicit and explicit non-existence differently. And neither interpretation is wrong per contract.
I think we’re fully in agreement here: if the API doesn’t specify how to handle null values, that omission means they’re perfectly valid and expected.
Imagine a delivery company’s van exploding if somebody attempts to ship an empty box. That would be a very poorly built van.
Billion dollar mistake
For those who don’t know:
Speaking at a software conference in 2009, Tony Hoare hyperbolically apologized for “inventing” the null reference:[26] [27]
I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn’t resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.
