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

31–40 of 83 posts

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

#31

Post by pron »

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

That's not the reason. The question was about JSON generation from existing Java types, not about a DSL. Java JSON libraries offer similar conveniences (in fact, you can be much more sophisticated, clear, and convenient than the DSL you've shown), but this particular library, as explicitly described in the JEP, is not intended to be a general-purpose JSON library, of which Java already has several good and popular ones.

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

#32

Post by dtech »

pron wrote: post #31
dtech wrote: post #28

Earlier quoted context omitted.

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

That's not the reason. The question was about JSON generation from existing Java types, not about a DSL. Java JSON libraries offer similar conveniences (in fact, you can be much more sophisticated, clear, and convenient than the DSL you've shown), but this particular library, as explicitly described in the JEP, is not intended to be a general-purpose JSON library, of which Java already has several good and popular on…

That's not what the person I replied to asked at all, arbitrary types weren't mentioned.

They literally asked why they couldn't write JsonObject.of(Map.of(...))

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

#33

Post by pron »

dtech wrote: post #32
pron wrote: post #31

Earlier quoted context omitted.

That's not the reason. The question was about JSON generation from existing Java types, not about a DSL. Java JSON libraries offer similar conveniences (in fact, you can be much more sophisticated, clear, and convenient than the DSL you've shown), but this particular library, as explicitly described in the JEP, is not intended to be a general-purpose JSON library, of which Java already has several good and popular on…

That's not what the person I replied to asked at all, arbitrary types weren't mentioned. They literally asked why they couldn't write JsonObject.of(Map.of(...))

And there's nothing in Java preventing that. In fact, it is trivial to implement that exact API on top of the API proposed in the JEP.

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

#34

Post by nikeee »

I don't like this:

    String body = ... REST response body, which is a JSON document ... ;
    JsonValue json = Json.parse(body);
    json.get("properties").get("periods").asList().stream()
        .mapToInt(j -> j.get("temperature").asInt())
        .average()
        .ifPresent(IO::println);
Why am I able to call `.get(string)` or `.get(int)` on a JsonValue? Shouldn't these be on the JsonObject and JsonArray instead?

> If the JsonValue instance is of the wrong type, or if the requested member or element does not exist, the access methods throw a JsonValueException.

So if I get an exception, I can't tell whether the value was of the wrong type or the object didn't have the requested key? This looks like a footgun to me.

They just brought pattern matching to Java. Why not move those .get to JsonArray and JsonObject? That would solve this confusions. So we could just use something like `if (json instanceof JsonObject o) o.get("properties")`

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

#35

Post by Hackbraten »

pron wrote: post #25
vlaaad wrote: post #20

Earlier quoted context omitted.

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.

Because JSON types don't cleanly map to Java types. For example, a JSON number could be an int, a long, a double, a BigInteger, or a BigDecimal. Which of them the Java code wants is not something you can deduce (most generally, you could represent all JSON numbers as BigDecimal, but that's not very convnient in Java code, so in most cases you'd want to convert that to a primitive type of your choosing anyway). A JSON…

Good point for parsing. However, the example is about serialization. What mapping ambiguity do you see there?

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

#36

Post by cute_boi »

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…

Even Rust syntax is so much clean and better than this...

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

#37

Post by marginalia_nu »

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…

Yeah, I agree.

The clean way of doing this is to build a json marshaling mechanism for the type system as it already exists. This is doable in Java, and some json libraries (e.g. gson) are already capable of this.

I must admit I don't fully understand the motivation behind this JEP. Like when would I ever reach for this?

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

#39

Post by singron »

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…

Currently, JsonObject.of has this signature:

    static JsonObject of(Map map);
java.lang.String and other types don't extend JsonValue, and java lacks any trait-like way to add this functionality to existing types, so you would have to change the signature to this:

    static JsonObject of(Map map);
Now you can pass any Object in, but the typechecker can't ensure that it is convertible to json anymore. I.e. it will have to check at runtime that it's either JsonValue or another type that is has a known conversion for (Integer, Double, String, List, Map, etc.). The jackson ObjectMapper e.g. has a lot of configuration available to tell it how to do these conversions on arbitrary types, and I think they want to eliminate that kind of ceremony.

It does seem like any serious application is going to use another library, and this will be useful for very simple json usage or single-file hello-world type programs (e.g. to go along with Implicitly Defined Classes and the Flexible Launch Protocol).

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

#40

Post by prpl »

pron wrote: post #25
vlaaad wrote: post #20

Earlier quoted context omitted.

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.

Because JSON types don't cleanly map to Java types. For example, a JSON number could be an int, a long, a double, a BigInteger, or a BigDecimal. Which of them the Java code wants is not something you can deduce (most generally, you could represent all JSON numbers as BigDecimal, but that's not very convnient in Java code, so in most cases you'd want to convert that to a primitive type of your choosing anyway). A JSON…

Yeah you could go with just Number though, and then keep almost everything a BigInteger/BigDecimal under the covers (or dynamically choose the correct class)
Post reply on HN