Hi I have been working on an adaptation of gwt-jackson that uses APT instead of generators
https://github.com/vegegoku/gwt-jackson-apt now i have plans to support using the same API for both client side and server side and want to consider the JsXxxx types as supported types for Serialization/Deserialization. If anyone is interested i welcome any type of feedback On Monday, December 11, 2017 at 2:25:04 PM UTC+2, Thomas Broyer wrote: > > 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/0717717c-786b-46ad-b89c-c5c29c3b96f5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
