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

11–20 of 83 posts

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

#12

Post by dfabulich »

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 convert each value into a JsonValue. And why am I forced to convert a native List into a JsonArray just so I can make it the value of a JsonObject?

Why can't I write this?

   JsonObject.of(Map.of("providers", List.of("SUN", "SunRsaSign", SunEC"))));

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

#14

Post by lmz »

q3k wrote: post #8

Happy to see that numbers are arbitrary width/precision until explicitly cast by the user. This goes against so many other JSON libraries that will always cast all numbers to double (or even float) thereby silently corrupting JSON numbers representing large values (eg. memory addresses). Does anyone know how this behaves when encountering a repeated key in an object? (RFC8259 states that keys SHOULD be unique, which…

Not sure why they didn't include the BigDecimal conversion directly on the JsonNumber object instead of going through the String representation.

Duplicate keys are a parse exception.

> Additionally, documents must not have objects with duplicate member names.

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

#15

Post by delusional »

They're doing a real API instead of the magic annotation hell that JavaEE fans love. Thank god. I welcome this, because Java has a lot of need for a good, common, performant, and well maintained JSON library that doesn't come along with the complexity of being JSON-B.

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

#16

Post by nlitened »

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…

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"]}))

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

#17

Post by rf15 »

whaley wrote: post #6

Meanwhile, Jackson has been going strong for almost 20 years now https://github.com/FasterXML/jackson . One of my favorite things about Jackson was being able to arbitrarily navigate through the document with a rich and fluent API (JsonNode) in jackson.databind, which this JEP at least conceptually borrows from with the JsonValue abstraction. Both of these are better than how some of the other implementations do it,…

But isn't JSON de facto conceptually a glorified Map ?

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

#18

Post by drdexebtjl »

gavinray wrote: post #3

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 N…

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.

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

#19

Post by Groxx »

Sankozi wrote: post #11

Using JSON as a configuration format is a big mistake. JEP authors could learn a bit from package.json problems. Hope JSON will not be used in anything significant for JDK configuration.

Yeah - json is fine as a readable mechanical exchange format, but without comments it's essentially unusable for anything humans need to touch :/

I'm somewhat boggled that json5 hasn't grown to be more of a thing.

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

#20

Post by vlaaad »

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…

Yes, what's the point of JsonObject at all? Why JsonString when there is String? Why JsonArray when there is List? JDK only needs a function to convert from JSON format to the normal data structures it already has and back.
Post reply on HN