Create Parse Tree without Java Model

[Jacob]

json-marshaller provides a JSONObject because it marshals a Java Model
into a JSONObject then this JSONObject can be written to a String.

Some of our models are very simple and we do not have Java objects
representing them. We are able to create a JSONObject and add a few
properties to create the JSON directly. This allows us to create
valid JSON without worrying about escaping and {:, placement.

Does GSON provide a way to create valid JSON without creating a Java
Model?

[inde...@gmail.com]

If I understand you correctly, what you want is an ability to build a
parse tree yourself and then use Gson to create the JSON string out of
it.

That seems like a reasonable request. How would you like to change the
Gson API to address this?

What if we added a method to Gson class:

public String toJson(JsonElement rootNodeOfParseTree)

Inder

[Jacob]

I am not sure how that would be different from JsonElement.toString().

Here are a couple use cases I don't know how to do in GSON.
1)
String json =
"{\"description\":\"A person\", \"type\":\"object\",
\"properties\": { \"name\": {\"type\":\"string\"}, \"born\" : {\"type
\":[\"integer\",\"string\"], \"minimum\":1900, \"maximum\":2010,
\"format\":\"date-time\", \"optional\":true}, \"gender\" : {\"type\":
\"string\", \"enum\":[\"male\",\"female\"], \"options\":[ {\"value\":
\"male\",\"label\":\"Guy\"}, {\"value\":\"female\",\"label\":\"Gal
\"}]}, \"address\" : {\"type\":\"object\" , \"properties\":{ \"street
\":{\"type\":\"string\"}, \"city\":{\"type\":\"string\"}, \"state\":
{\"type\":\"string\"} } } } }";
JsonObject jsonObject = new JsonObject(json);

2).
Foo foo = new Foo();
JsonObject jsonObject = new Gson().toJson(foo);

Jacob

[inde...@gmail.com]

On Oct 20, 12:15 pm, Jacob <jacob.to...@gmail.com> wrote:
> I am not sure how that would be different from JsonElement.toString().

Good point.

> Here are a couple use cases I don't know how to do in GSON.
> 1)
>         String json =
>                 "{\"description\":\"A person\", \"type\":\"object\",
> \"properties\": { \"name\": {\"type\":\"string\"}, \"born\" : {\"type
> \":[\"integer\",\"string\"], \"minimum\":1900, \"maximum\":2010,
> \"format\":\"date-time\", \"optional\":true}, \"gender\" : {\"type\":
> \"string\", \"enum\":[\"male\",\"female\"], \"options\":[ {\"value\":
> \"male\",\"label\":\"Guy\"}, {\"value\":\"female\",\"label\":\"Gal
> \"}]}, \"address\" : {\"type\":\"object\" , \"properties\":{ \"street
> \":{\"type\":\"string\"}, \"city\":{\"type\":\"string\"}, \"state\":
> {\"type\":\"string\"} } } } }";
>         JsonObject jsonObject = new JsonObject(json);
>
> 2).
>         Foo foo = new Foo();
>         JsonObject jsonObject = new Gson().toJson(foo);

I see. What you really want is just the JSON parser from Gson.
We have thought about exposing the Parser API, but were not entirely
comfortable with the API as designed so chose to expose it later.
Let us get a discussion going on what will be a good API.

How about if we provide a JsonParser class, that looked like this:

public class JsonParser {
public JsonParser(Reader reader) { ... }
public JsonParser(String string) { .... }

public JsonElement parse() { ... }
}

[Jacob]

This looks good.

What are its advantages over adding a constructor to JsonObject?

Would making JsonParser more like a factory class be better?
public class JsonParser {
public JsonElement parse(String string) {...}
public JsonElement parse(Reader reader) {...}

Jacob

[inde...@gmail.com]

The factory class is a better approach because in the other approach a
subsequent invocation of the parse() method will cause problems.
Also, if it is a real object, then we have to worry about the
semantics of other object methods such as equals, hashcode, toString
etc.

Besides, JsonParser as currently generated from JavaCC is a factory
class. We will not use that class though since JavaCC exposes lots of
unneeded stuff.

Another question: should we keep it in the same package
(com.google.gson) or a different one (com.google.gson.parser) . Moving
it to the parser package is going to be cleaner but probably much
harder. Besides it will look odd that the parser objects (JsonElement
and its subclasses) live in another package.

[inde...@gmail.com]

I created an issue to track this.
http://code.google.com/p/google-gson/issues/detail?id=65

[Jacob]

As for the package I think you have accurately summed it up. Does the
thought of needing to move it in the future when it will be even
harder push enough toward doing it now. Or do we think that the clean
separation will not be needed.

What are the ruled for version numbers? Would package change be the
type of thing that could only come in 2.0?

Jacob

[inde...@gmail.com]

> What are the ruled for version numbers?  Would package change be the
> type of thing that could only come in 2.0?

The only convention we follow is that if there is any changes in the
public API of Gson, we increment the rel.dot version. If the release
only contains bugfixes, we increment rel.dot.dot version. We dont
really have any convention for changing the major release number but
it probably makes sense to change that for substantially added
functionality or when we go beyond 1.9.

But now you got me thinking: may be this is a fairly substantial new
functionality that merits a new major release number. We also have a
bunch of other API changes lined up (see the issue tracker).

We will always maintain backward compatibility, so the current
JsonElement and its subclasses will remain where they are. If there
was a compelling reason, we could deprecate them and create new set of
classes under parser package. But the current situation obvious does
not merit that kind of a solution.

[Jacob]

Inder,

Before this is added, if the code below the most compact way of doing
this?

Thanks,
Jacob

JsonObject obj =
new
GsonBuilder().registerTypeAdapter(JsonObject.class,
new JsonDeserializer<JsonObject>() {

public JsonObject deserialize(JsonElement
json, Type typeOfT,
JsonDeserializationContext
context) throws JsonParseException {
return json.getAsJsonObject();
}
}).create().fromJson(result,
JsonObject.class);

[Inderjeet Singh]

That is not what I was planning.
I was planning to provide a new JsonParser class that will provide
(independent of Gson) an ability to parse a Json String into a tree of
JsonObjects. So, there should be no need to register a deserializer
for JsonObject.

But you got me thinking. The user is probably going to expect that
they be able to apply their custom type adapters after manipulating
the Json parse tree. One way to do that would be to serialize the Json
parse tree into a string again, and the feed it to Gson.fromJson().
That works though is inefficient.

Inder

[Jacob Tomaw]

I am just using this in an interim basis until a final solution is determined upon.

My use cases do not call for the use of any custom adapters.  I only need to parse a JSON String into a map.  I don't think i have provided anything concrete in this thread so here are two.

1) {"version":0, "data":{"memberId":"12345678"}}
It seems like overkill to create a model for this.

2) Testing (This is where my desire for a proper equals)
I have some logic that does work and returns a JSON string.  As 2 JSON strings can be different bu equal and my client may not have the same model at me, I would like to be able to parse the string and then .equals it to a JsonObject I created by hand to make sure is it correct.

Thanks,
Jacob

--
Jacob Tomaw
tfl:The Flatiron Life (http://tomaw.com)
Follow me on Twitter! (http://twitter.com/JacobTomaw)