Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JEP 540: Simple JSON API (Now in Incubator)

openjdk.org

Post reply on HN
Print view View original

61–70 of 83 posts

Re: JEP 540: Simple JSON API (Now in Incubator)

#61

Post by wduquette »

dfabulich wrote: post #12

A stated goal of the API is to have "low ceremony"; this seems like a lot of ceremony. IO.println(JsonObject.of(Map.of("providers", JsonArray.of(List.of(JsonString.of("SUN"), JsonString.of("SunRsaSign"), JsonString.of("SunEC")))))); There's gotta be a better way! Surely there could be some way of creating a JsonArray of native Java Strings, Booleans, Doubles, and Integers without requiring clients to explicitly conve…

A stated goal of the API is to have "low ceremony" when reading arbitrary JSON files. I agree the JSON creation API looks pretty clunky, but the parsing API looks fairly simple.

Re: JEP 540: Simple JSON API (Now in Incubator)

#62

Post by fallingbananna »

owlstuffing wrote: post #47
dfabulich wrote: post #12

A stated goal of the API is to have "low ceremony"; this seems like a lot of ceremony. IO.println(JsonObject.of(Map.of("providers", JsonArray.of(List.of(JsonString.of("SUN"), JsonString.of("SunRsaSign"), JsonString.of("SunEC")))))); There's gotta be a better way! Surely there could be some way of creating a JsonArray of native Java Strings, Booleans, Doubles, and Integers without requiring clients to explicitly conve…

You can inline native type-safe JSON directly in Java with the manifold project. /*[Dude.json/] { "Name": "Scott", "Age": 100, "Address": { "Street": "345 Syracuse Way", "City": "Atlantis" } } */ Dude dude = Dude.fromSource(); out.println(dude.getName()); out.println(dude.getAge()); out.println(dude.getAddress().getCity()); https://github.com/manifold-systems/manifold

You could... but I view JSON as a simple format that you could write a recursive parser for in a few hundred lines yourself.

Bringing in compile-time code generation just for defining static JSONs (which is not that common outside of tests, as most JSONs are serialized and deserialized at runtime) sounds like a hard sell.

Re: JEP 540: Simple JSON API (Now in Incubator)

#63

Post by Someone »

dfabulich wrote: post #12

A stated goal of the API is to have "low ceremony"; this seems like a lot of ceremony. IO.println(JsonObject.of(Map.of("providers", JsonArray.of(List.of(JsonString.of("SUN"), JsonString.of("SunRsaSign"), JsonString.of("SunEC")))))); There's gotta be a better way! Surely there could be some way of creating a JsonArray of native Java Strings, Booleans, Doubles, and Integers without requiring clients to explicitly conve…

> Surely there could be some way of creating a JsonArray of native Java Strings, Booleans, Doubles, and Integers without requiring clients to explicitly convert each value into a JsonValue

I think so to, and it surprises me that they write

“A key goal driving the recent evolution of the Java Platform has been to enable simple tasks to be accomplished more easily and with less ceremony. Features serving this goal include convenience factory methods for collections […]”

and don’t, from that, decide that this API needs such factory methods.

The API also doesn’t make JsonObject or JsonArray collections, requiring one to use ‘asMap’ or ‘asArray’ before iterating over them.

What benefit does that carry? That one can implement those interfaces as records?

Re: JEP 540: Simple JSON API (Now in Incubator)

#64

Post by crewindream »

jonenst wrote: post #60

I find it very surprising that they went for unchecked exceptions. For JsonValueException the following rationale is given "This exception is unchecked, so that scripts and small programs are easier to read and write." But for JsonParseException there is no rationale. This is surprising especially given the pushback from openjdk members against jackson3 moving to unchecked exception.

I’m very happy that these exes are unchecked (incl jackson3).

If parsing fails - how often can you do anything else than just abort and log/show an error..

Checked exceptions are nice in theory, but it is very context dependent if checked’ness is useful, I would prefer that libraries do not expose them.

Re: JEP 540: Simple JSON API (Now in Incubator)

#65

Post by agumonkey »

pron wrote: post #48
packetlost wrote: post #42

Earlier quoted context omitted.

You really can't appreciate how awesome Clojure is until you're coming from Java, can you...

And vice versa. As someone who likes both languages, I appreciate how they both have their pros and cons. I was a Schemer before I learnt Java (when Java barely existed) and I adore Clojure, but if I were to write 10 MLOC mobile network routing and billing system, an air-traffic control system, or a credit-card transaction processing system etc. etc. that needs to evolve by a large team for 20 years, I would choose J…

Interesting how we need two sides balancing each others.

Re: JEP 540: Simple JSON API (Now in Incubator)

#66

Post by layer8 »

packetlost wrote: post #42
nlitened wrote: post #16

Earlier quoted context omitted.

There's a nice Java library called Clojure with a lightweight syntax if you need to work with data structures and concurrency in Java a lot: (println (json/generate-string {:providers ["SUN" "SunRsaSign" "SunEC"]}))

You really can't appreciate how awesome Clojure is until you're coming from Java, can you...

Dynamically typed languages by their nature always have an easier time with (de)serialization.

Re: JEP 540: Simple JSON API (Now in Incubator)

#67

Post by layer8 »

dtech wrote: post #28
dfabulich wrote: post #12

A stated goal of the API is to have "low ceremony"; this seems like a lot of ceremony. IO.println(JsonObject.of(Map.of("providers", JsonArray.of(List.of(JsonString.of("SUN"), JsonString.of("SunRsaSign"), JsonString.of("SunEC")))))); There's gotta be a better way! Surely there could be some way of creating a JsonArray of native Java Strings, Booleans, Doubles, and Integers without requiring clients to explicitly conve…

Java lacks the expressiveness to make it much better than this. There's a reason almost all the "replacement Java" languages add something to support DSLs, e.g. type safe builders in Kotlin [1] The kotlin stdlib-adjacent json lib does it like this buildJsonObject { putJsonArray("providers") { add("SUN") add("SunRsaSign") add("SunEC") } } [1] https://kotlinlang.org/docs/type-safe-builders.html

> Java lacks the expressiveness to make it much better than this.

That's not really true. You can have a Java library providing:

    Json.writeTo(System.out)
        .object()
            .array("providers")
                .element("SUN")
                .element("SunRsaSign")
                .element("SunEC")
            .end()
        .end();
or as a shortcut

    Json.writeTo(System.out)
        .object()
            .array("providers").withElements("SUN", "SunRsaSign", "SunEC")
        .end();
or similar (aka faceted fluent API), with typed interfaces mirroring the grammar of the target language, here JSON.

This is basically a structured output iterator (or OutputStream-like) pattern. It can also support modularization such that substructures can be factored out into separate methods or lambdas, thereby also allowing loops and conditionals.

Such an API can be provided in a relatively compact fashion and would be nicer than what the JEP proposes.

Re: JEP 540: Simple JSON API (Now in Incubator)

#68

Post by jamesfinlayson »

BoorishBears wrote: post #59
nlitened wrote: post #16

Earlier quoted context omitted.

There's a nice Java library called Clojure with a lightweight syntax if you need to work with data structures and concurrency in Java a lot: (println (json/generate-string {:providers ["SUN" "SunRsaSign" "SunEC"]}))

I prefer its sibling library Kotlin, from the makers of the world famous Java IDE: Jetbrains Fleet

I'm pretty partial to Groovy's JSON library - it has a nice syntax it just works (caveat that I had issues once where the size of the JSON was multiple megabytes and it corrupted).

Re: JEP 540: Simple JSON API (Now in Incubator)

#69

Post by owlstuffing »

fallingbananna wrote: post #62
owlstuffing wrote: post #47

Earlier quoted context omitted.

You can inline native type-safe JSON directly in Java with the manifold project. /*[Dude.json/] { "Name": "Scott", "Age": 100, "Address": { "Street": "345 Syracuse Way", "City": "Atlantis" } } */ Dude dude = Dude.fromSource(); out.println(dude.getName()); out.println(dude.getAge()); out.println(dude.getAddress().getCity()); https://github.com/manifold-systems/manifold

You could... but I view JSON as a simple format that you could write a recursive parser for in a few hundred lines yourself. Bringing in compile-time code generation just for defining static JSONs (which is not that common outside of tests, as most JSONs are serialized and deserialized at runtime) sounds like a hard sell.

This is just a small part of manifold’s JSON integration. And, yes, the inline aspect is mostly for testing, and it’s awesome there.

Re: JEP 540: Simple JSON API (Now in Incubator)

#70

Post by peterabbitcook »

pron wrote: post #30
dfabulich wrote: post #12

A stated goal of the API is to have "low ceremony"; this seems like a lot of ceremony. IO.println(JsonObject.of(Map.of("providers", JsonArray.of(List.of(JsonString.of("SUN"), JsonString.of("SunRsaSign"), JsonString.of("SunEC")))))); There's gotta be a better way! Surely there could be some way of creating a JsonArray of native Java Strings, Booleans, Doubles, and Integers without requiring clients to explicitly conve…

I'm not involved with the design of this API, but it seems to me that the issue on the JSON generation side (where you're complaining about ceremony) is feature creep. Creating the API you want on top of the proposed one is trivial (even in user code), but then where do you stop? If you have that conversion, it seems reasonable to also support, say, sets and records; maybe even enums. Indeed, Java JSON libraries typi…

Where to stop is a pretty fuzzy question I suppose.

In my world, I think the worst possible outcome would be a java.util.json library that does 50-95% of what I currently do with GSON or Jackson. In that scenario I still need an external dependency, and I can either ignore java.util.json or turn a codebase into an error-prone mix of both.

Maybe a good set of design considerations for java.util.json would be “what does this API need to run a CRUD app written in modern java?” Parse requests from the web, send responses to the web, and serialize/deserialize data from X database (e.g. if noSQL or jsonb). In my head “in modern java” would mean that JSON is converted to records at application boundaries

Post reply on HN