Re: [gwt-contrib] Which API for a future, modern JSON library?

[Thomas Broyer]

On Monday, December 11, 2017 at 9:39:52 PM UTC+1, Peter Donald wrote:
>
> Hi, 
>
> Have you considered the javax.json API?


No, just like I didn't consider org.json.
 

> There are some parts that may 
> not be able to be directly translated but from memory it should mostly 
> work. The "advantage" is that it is a standard that is starting to 
> gain traction and will likely be present in lots more APIs as more of 
> the EE stack adopts it. The "disadvantage" is that the api is a bit 
> more primitive and it evolves slowly. It could probably be done with 
> just @JsOverlay methods and a few adapter classes.


I think it would mostly involve adapter classes (JsonObject extends Map, 
JsonArray extends List; so they cannot be implemented as native types)
 

> Another 
> disadvantage is that it is an immutable/read-only API. 
>

It's actually not: JsonObjectBuilder and JsonArrayBuilder allow 
constructing values.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/5dbdcd27-d141-4b07-935e-4ec5e994ddc1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Which API for a future, modern JSON library?

[Peter Donald]

Hi,

Have you considered the javax.json API? There are some parts that may
not be able to be directly translated but from memory it should mostly
work. The "advantage" is that it is a standard that is starting to
gain traction and will likely be present in lots more APIs as more of
the EE stack adopts it. The "disadvantage" is that the api is a bit
more primitive and it evolves slowly. It could probably be done with
just @JsOverlay methods and a few adapter classes. Another
disadvantage is that it is an immutable/read-only API.

As for json writing - We tend to use @JsType annotated classes and
have yet to come up with a use case where we would need to drop down
to JsPropertyMap.

-- 
Cheers,

Peter Donald

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CACiKNc6_RvyT7RaQ8r87bXcexVvGB%2BmtFCiATZrY-aNcB%2BYKEg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Which API for a future, modern JSON library?

[Thomas Broyer]

Hi all,

Following up 
on https://github.com/gwtproject/gwt/issues/9484#issuecomment-277216304, 
I've been toying around to build a new JSON library for GWT.
Note that my goal is to have a lightweight library that could be used both 
on the client-side with GWT (and then j2cl), and on the server-side or in 
any JVM; and "mapping" to/from POJOs is (currently) out of scope.

What do you think would be the best API?


   - Same as com.google.gwt.json.
   This API is IMO verbose, and is based on wrapper objects that add 
   runtime overhead.
   - Same as elemental.json, except for JsonNull which goes away 
   (represented by a Java 'null' and interchangeable with 'undefined').
   Lighter-weight, both in terms of API verbosity and runtime overhead (no 
   wrapper object).
   Based on type coercion (you can ask every JsonValue to be returned as a 
   boolean, double, or String, and value will be coerced accordingly).
   elemental.json "JRE" types are also usable on client-side, and can be 
   transported through GWT-RPC; I believe this is an aspect that we cannot 
   preserve.
   - Similar to jsinterop-base's Any, JsPropertyMap and JsArrayLike (for 
   JsonValue, JsonObject and JsonArray respectively), and using Java String 
   and primitives for other value types; and probably with the addition of a 
   JsonType enum (or isXxx methods) on Any/JsonValue to be able to tell value 
   types apart before you call the (throwing) asXxx methods.
   This is actually similar to elemental.json but without the JsonBoolean, 
   JsonNumber, and JsonString types; and it throws rather than coercing values.
   This could even go farther and directly use JsonValue[] instead of 
   JsonArray.
   - Something else?

One question also is whether this should be used for consuming JSON mostly, 
or also for creating JSON (you'd generally use POJOs and serialize them to 
JSON I believe, but there may be cases where you want to create a dynamic 
structure that you cannot easily represent as a tree of POJOs), and/or 
"updating/modifying JSON" (parse, update, stringify).

Fwiw, this would also be a good opportunity to shape how a cross-platform 
library would be developed in terms of project layout and tooling (in both 
Gradle and Maven).

Wrt the JVM/server-side support, what JSON parsing library should be used? 
I was heading towards the lightweight Moshi from Square, but I believe 
there could possibly be several "adapters" for Moshi, GSON, Jackson, etc. 
(and even org.json's JsonTokenizer/JsonStringer)

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/8798ff67-2a53-462b-95f7-2e2d9e953b71%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.