[gavinray]

It used to be the case that if you wanted to build a web service on the JVM, you wanted 2 things:

1. An HTTP server library/framework

2. A JSON library

We got a decently-performing and unopionated HTTP server in JDK 18 with "HttpHandlers" and "SimpleFileServer" plus "jwebserver" CLI

It later received Virtual Thread support, which made performance + scalability very competitive.

With a JSON module, you finally won't NEED to rely on external deps to build a basic JVM web service without pain.

Now, we just need a proper CLI framework like picocli, or at least "argparse" from Python stdlib...

[drdexebtjl]

My understanding from reading this is the complete opposite. This library is explicitly not supporting the features that web servers need to be performant and handle production traffic, like streaming.

A web server using this could only start parsing when it receives the last byte, and could only start responding when it’s done serializing, all while holding non-lazy trees of JsonValue objects in memory.

[wewtyflakes]

I suspect the vast majority of services are not dealing with such massive JSON documents that doing serde on them becomes a material part of their latency breakdown.

[gavinray]

I've never built or worked on a service where the JSON payloads were so large that (de)serialization accounted for a significant portion of the timing profile

I'm sure lots of them exist, but for your typical CRUD API, this has not been a phenomena I've run into.

[drdexebtjl]

I don’t have any benchmarks, but it’s surprisingly relevant. Not necessarily because parsing JSON is slow, but because managing memory is slow, and you’re dealing with potentially malicious input.

A non-streaming implementation needs to copy the request from the network stack into a contiguous GC-managed char array, possibly resizing it a few times as the data is received. Then when it’s time to parse, it goes through this array and allocates an unbounded number of JsonValue nodes. For JsonString and JsonNumber, it probably needs to create defensive copies of the data instead of spans of the input array, otherwise changing the input array corrupts the tree.

That’s kinda bad under memory pressure even for benign inputs. But consider malicious inputs, such as {"x":{"x":{"x":{"x":{"x":{…}}}}}. It would make this non-streaming implementation allocate a lot of String and JsonObject instances. The allocations would total multiple times the size of the input, and would be extremely fragmented.

On the other hand, a library that does streaming and that binds to objects could parse straight from the buffers in the network stack, and could avoid allocating objects for anything that it will not need to bind.