this post was submitted on 30 Jun 2024
284 points (94.9% liked)

Programmer Humor

19699 readers
110 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 1 year ago
MODERATORS
 

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.”

top 50 comments
sorted by: hot top controversial new old
[–] [email protected] 32 points 4 months ago* (last edited 4 months ago) (2 children)

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).

[–] [email protected] 53 points 4 months ago (1 children)

They're semantically different for PATCH requests. The first does nothing, the second should unset the name field.

[–] expr 6 points 4 months ago (5 children)

Only if using JSON merge patch, and that's the only time it's acceptable. But JSON patch should be preferred over JSON merge patch anyway.

Servers should accept both null and undefined for normal request bodies, and clients should treat both as the same in responses. API designers should not give each bespoke semantics.

[–] arendjr 3 points 4 months ago (1 children)

JSON patch is a dangerous thing to use over a network. It will allow you to change things inside array indices without knowing whether the same thing is still at that index by the time the server processes your request. That’s a recipe for race conditions.

[–] expr 2 points 4 months ago

That's what the If-Match header is for. It prevents this problem.

That being said, I generally think PUTs are preferable to PATCHes for simplicity.

load more comments (4 replies)
[–] [email protected] 8 points 4 months ago (1 children)

Ya, having null semantics is one thing, but having different null and absent/undefined semantics just seems like a bad idea.

[–] [email protected] 39 points 4 months ago (5 children)

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.

[–] expr 8 points 4 months ago (1 children)

Zalando explicitly forbids it in their RESTful API Guidelines, and I would say their argument is a very good one.

Basically, if you want to provide more fine-grained semantics, use dedicated types for that purpose, rather than hoping every API consumer is going to faithfully adhere to the subtle distinctions you've created.

[–] [email protected] 4 points 4 months ago* (last edited 4 months ago) (1 children)

They're not subtle distinctions.

There's a huge difference between checking whether a field is present and checking whether it's value is null.

If you use lazy loading, doing the wrong thing can trigger a whole network request and ruin performance.

Similarly when making a partial change to an object it is often flat out infeasible to return the whole object if you were never provided it in the first place, which will generally happen if you have a performance focused API since you don't want to be wasting huge amounts of bandwidth on unneeded data.

[–] expr 0 points 4 months ago (1 children)

The semantics of the API contract is distinct from its implementation details (lazy loading).

Treating null and undefined as distinct is never a requirement for general-purpose API design. That is, there is always an alternative design that doesn't rely on that misfeature.

As for patches, while it might be true that JSON Merge Patch assigns different semantics to null and undefined values, JSON Merge Patch is a worse version of JSON Patch, which doesn't have that problem, because like I originally described, the semantics are explicit in the data structure itself. This is a transformation that you can always apply.

[–] [email protected] 2 points 4 months ago* (last edited 4 months ago) (1 children)

No there isn't.

Tell me how you partially change an object.

Object User :

{ Name: whatever, age: 0}

Tell me how you change the name without knowing the age. You fundamentally cannot, meaning that you either have to shuttle useless information back and forth constantly so that you can always patch the whole object, or you have to create a useless and unscalable number of endpoints, one for every possible field change.

As others have roundly pointed out, it is asinine to generally assume that undefined and null are the same thing, and no, it flat out it is not possible to design around that, because at a fundamental level those are different statements.

[–] expr -1 points 4 months ago (1 children)

As I already said, it's very simple with JSON Patch:

[
  { *op": "replace", "path": "/Name™, "value": "otherName"}
]

Good practice in API design is to permissively accept either undefined or null to represent optionality with same semantics (except when using JSON Merge Patch, but JSON Patch linked above should be preferred anyway).

[–] [email protected] -1 points 4 months ago* (last edited 4 months ago) (1 children)

I.e. waste a ton of bandwidth sending a ridiculous amount of useless data in every request, all because your backend engineers don't know how to program for shit.

Gotcha.

[–] expr 2 points 4 months ago

It's about making APIs more flexible, permissive, and harder to misuse by clients. It's a user-centric approach to API design. It's not done to make it easier on backend. If anything, it can take extra effort by backend developers.

But you'd clearly prefer vitriol to civil discourse and have no interest in actually learning anything, so I think my time would be better spent elsewhere.

[–] [email protected] 5 points 4 months ago* (last edited 4 months ago)

This is also how it is defined in the JSON Merge Patch RFC.

[–] [email protected] 3 points 4 months ago

it does feel ambiguous though as even what you outlined misses a 4th case. if null means delete, how do I update it to set the field to null?

[–] 0x0 1 points 4 months ago

It gets more fun if we're talking SQL data via C API: is that 0 a field with 0 value or an actual NULL? Oracle's Pro*C actually has an entirely different structure or indicator variables just to flag actual NULLs.

[–] sukhmel -1 points 4 months ago (1 children)

Except, if you use any library for deserialization of JSONs there is a chance that it will not distinguish between null and absent, and that will be absolutely standard compliant. This is also an issue with protobuf that inserts default values for plain types and enums. Those standards are just not fit too well for patching

[–] [email protected] 2 points 4 months ago (1 children)

I've never once seen a JSON serializer misjudge null and absent fields, I've just seen developers do that.

[–] sukhmel 0 points 4 months ago (1 children)

Well, Jackson before 2.9 did not differentiate, and although this was more than five years ago now, this is somewhat of a counter example

Also, you sound like serializers are not made by developers

[–] [email protected] 0 points 4 months ago* (last edited 4 months ago)

Bruh, there's a difference between the one or two serializing packages used in each language, and the thousands and thousands and thousands of developers who miscode contracts after that point.

[–] [email protected] 21 points 4 months ago (1 children)
[–] [email protected] 38 points 4 months ago (1 children)

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.

https://en.wikipedia.org/wiki/Tony_Hoare

[–] [email protected] 8 points 4 months ago

Huh, so Tony Hoare invented null and then Graydon Hoare invented Rust, ~~immediately terminating the existence of null~~ which does not have a traditional null value.

[–] [email protected] 15 points 4 months ago (5 children)

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?

[–] [email protected] 18 points 4 months ago

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.

[–] [email protected] 7 points 4 months ago* (last edited 4 months ago)

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.

[–] [email protected] 3 points 4 months ago

You can always bind the JSON to a hashmap implementation, as that’s all JSON is anyway. It’s not pretty but it works.

[–] [email protected] 2 points 4 months ago (1 children)

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.

[–] [email protected] 3 points 4 months ago (1 children)

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.

[–] [email protected] 0 points 4 months ago (2 children)

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.

[–] [email protected] 8 points 4 months ago

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.

[–] [email protected] 3 points 4 months ago (8 children)

Null means I'm telling you it's null.

Omission means it's not there and I'm not telling you anything about it.

There is a world of difference between those two statements. It's the difference between telling someone you're single or just sitting there and saying nothing.

[–] JackbyDev 1 points 4 months ago (1 children)

I (think, at least) the point they're making is that unless the API contract specifically differentiates between "present and null" and "absent" then there is no difference. (Specifically for field values.)

[–] [email protected] 0 points 4 months ago

The point I'm making is kind of the opposite, unless the contract explicitly states that they're the same they should not be treated as the same, because at a fundamental level they are not the same thing even if Java wants to treat them as such.

load more comments (7 replies)
[–] Nithanim 1 points 4 months ago

Java does not have the concept of "undefined", only "null". Also, json handling is only done via libraries so it also depends on what reads it. If the programmer defines the property as its type directly (here string), then the library reading has no way to convey the distinction between undefined or null. Either it uses null or throws. The jackson library can understand when the type is Optional. So the field would be null when undefined and an empty optional when null.

[–] [email protected] 11 points 4 months ago (1 children)
[–] [email protected] 3 points 4 months ago

I’m sad that there are people who call themselves developers who need to be told this.

[–] [email protected] 7 points 4 months ago
[–] JackbyDev 2 points 4 months ago (1 children)

Just what every programming language needs, not one, but two types of null! Because nobody ever said one type was difficult enough.

If I see any of you make this distinction matter for anything other than "PUT vs. PATCH" semantics I'm going to be very angry.

[–] [email protected] 1 points 4 months ago

I do this constantly. undefined: not retrieved yet. null: Error when retrieving. Makes it easy to reason about what the current state of the data is without the need for additional status flags.

[–] jamietanna 2 points 4 months ago

Had to solve this with Go recently, which was not as straightforward as I'd hoped! https://www.jvt.me/posts/2024/01/09/go-json-nullable/

load more comments
view more: next ›