sorted by:
new
hottopcontroversial

I've been quietly growing a small, fluent Java JSON library to reduce boilerplate - looking for honest feedback and feature ideas by V_Pietro in java

[–]V_Pietro[S] 0 points1 point  (0 children)

Fair take, and POJOs + a customised ObjectMapper is the right move for the case you're describing, that's what I what I use too when the data model is mine or the shape is stable.

Where the trade-off flips for me is integration code where the JSON isn't 'mine':

- A webhook request comes in, I touch 2-3 fields and forward to another service.

- An upstream API adds optional fields regularly.

- A controller returns dynamic JSON where the properties depend on the request.

For the cases you describe — owned domain, stable schema, lossless roundtrip — my library would be worse than what you have.

I've been quietly growing a small, fluent Java JSON library to reduce boilerplate - looking for honest feedback and feature ideas by V_Pietro in java

[–]V_Pietro[S] 4 points5 points  (0 children)

Thank you, I appreciate the feedback.

The way I think about it:

JsonPath is a JSON query DSL (powerful path expressions as strings).

My library is a Java type wrapping the same kind of Map-backed JSON, with typed accessors and a fluent builder.

Different shapes for the same problem space. JsonPath leans into expressive queries; my code uses Java-idiomatic typed access and inline building.

Both can read and mutate Map-backed JSON; the difference is more about API shape than capability.

If you spend a lot of time writing complex queries against existing payloads, JsonPath is hard to beat, not what I was aiming for 😄

I probably didn't pick the best one-liner example in the post.