Less strict parsing to make it easier to switch to gson? about google-gson HOT 10 CLOSED

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.

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.

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?

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? 

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

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

Added a test in r313

Fixed in r314