Ah yes the difference between “unset” and “intentionally set to null”, the bane of API devs who work in languages that don’t inherently distinguish between the two.

Well. To Java that’s just a string of utf-8 characters, assuming you haven’t bastardised the encoding, and it’s just yanked out of an HTTP entity. So of course they’re different.

If you’re using some json parser and object mapping library (like Jackson) then all bets are off 'cause it could be configured any which way.

On every other language and library it’s whatever the defined behaviour is.

3/10

If your Java dev is using Jackson to serialize to JSON, they might not be very experienced with Jackson, or they might think that a Java object with a null field would serialize to JSON with that field omitted. And on another project that might have been true, because Jackson can be configured globally to omit null properties. They can also fix this issue with annotations at the class/field level, most likely @JsonInclude(Include.NON\_NULL).

More details: https://www.baeldung.com/jackson-ignore-null-fields

C# devs be like

public string? Name { get; set; }

{"name": undefined} is also different, checking with something like hasOwn

This is true in Lua as well (substituting ‘nil’ for 'null)

That’s not legal serialized json, in the context of how any lib in Java (that I’m aware of) would either parse or render it.

Ignore me, I misremembered, sorry about that.

That’s what undefined is for