Less strict parsing to make it easier to switch to gson?

[GoogleCodeExporter]

gson appears to require all the elements to be strictly quoted. e.g. it
wants the format: { "hello": "world" }. Some other libraries like
net.sf.json and org.json are more relaxed and will also accept { hello:
"world" } but gson doesn't seem to accept this.

For example, the json.org api doc says: "Strings do not need to be quoted
at all if they do not begin with a quote or single quote, and if they do
not contain leading or trailing spaces, and if they do not contain any of
these characters: { } [ ] / \ : , = ; # and if they do not look like
numbers and if they are not the reserved words true, false, or null."

http://www.json.org/javadoc/org/json/JSONObject.html

It's arguable whether this behaviour is sensible / in spec, but to switch
to gson from my current library I'll have to change all my unit tests,
notify everyone who interacts with me that they may have to review / change
their JSON formatting etc etc. and cope with any resulting breakages.

Could more relaxed parsing behaviour be made an option maybe via an
alternate javacc parser?

Original issue reported on code.google.com by msmith99...@gmail.com on 8 Sep 2008 at 1:05

[GoogleCodeExporter]

This seems like a reasonable request.  According to the JSON specification, 
string
values should be quoted.

We will add an options on the Gson Builder to allow for "lenient" parsing; 
however,
all objects that get serialized by Gson (or your outgoing responses) will have 
quoted
string.  My gut instinct is that this should be fine since it abides by the JSON
spec, but I just wanted to make you aware that if you are currently returning 
JSON
responses with unquoted string then this may break your clients.

We will aim to get this into the 1.2.1 release which is slotted for early 
October.

Original comment by joel.leitch@gmail.com on 14 Sep 2008 at 7:30

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Original comment by joel.leitch@gmail.com on 14 Sep 2008 at 7:30

• Changed state: Accepted

[GoogleCodeExporter]

Thanks for your response. I think generating strings with quotes is fine. I was
worried about handling requests from people with other libraries. 

I agree that this new behaviour should be optional.

Original comment by msmith99...@gmail.com on 16 Oct 2008 at 4:55

[GoogleCodeExporter]

I am not clear about how it is even supposed to parse. If there are no quotes, 
what 
is the delimiter indicating end of a string?

Can someone point me to a library that handles unquoted strings?

Original comment by inder123 on 16 Oct 2008 at 5:09

[GoogleCodeExporter]

Ah I see that the request is being made for the field names, not values. There 
it 
makes a little more sense. 

Can the header names have arbitrary string values? Can they contain the ':' 
character 
? Can they contain the white space? 

Original comment by inder123 on 17 Oct 2008 at 10:27

[GoogleCodeExporter]

The initial post included a link to the javadoc for a library that supports 
this.

The values need to be quoted if they contain the characters you describe or are
reserved words etc. Additional rules as listed here:

http://www.json.org/javadoc/org/json/JSONObject.html

Original comment by msmith99...@gmail.com on 21 Oct 2008 at 3:44

[GoogleCodeExporter]

A slight variation on this is allowing *any* value that the parser otherwise
recognizes to be assigned to a String. In particular, I would like to see

{ "foo": 1}

be compatible with

class bar {
    String foo;
    };

Now, you get a gson exception stating in effect that a java.lang.Integer can't 
be
assigned to a java.lang String. But I thought *all* java objects had a 
toString()
function that could be used for the conversion? (Might be wrong on this in 
general,
but it is certainly true for Integer, Boolean, etc.)

The motivation for this, among other things, is that when you're first 
exploring a
new JSON source, you can declare everything to be a String, see what you get, 
then
make adjustments either in class declarations or in processing logic.

I suppose you could declare everything to be an Object and see what you get, 
but I
haven't (yet!) tried this and don't know how it works.

Thanks in advance,

Jim Renkel

Original comment by james.re...@gmail.com on 22 Oct 2008 at 4:14

[GoogleCodeExporter]

Original comment by joel.leitch@gmail.com on 25 Nov 2008 at 6:58

[GoogleCodeExporter]

Added a test in r313

Original comment by inder123 on 26 Nov 2008 at 6:27

[GoogleCodeExporter]

Fixed in r314

Original comment by inder123 on 26 Nov 2008 at 6:27

• Changed state: Fixed