I am working on a project (http://code.google.com/p/plovr/) that is trying
to use JSON as the format for a config file. The inability to comment
something out is making me consider XML instead :( You can see the
workaround that I'm using (which I believe is what Crockford recommends) here:
This is a pretty horrible option for multi-line comments, or when you are
experimenting and are frequently enabling/disabling various options.
I realize that // and /* comments are no longer part of the JSON spec, but
in practice, it would be great if it were possible to instantiate a
com.google.gson.JsonParser() in such a way that it would tolerate comments.
I believe some of the other JSON parsers offer this mode.
Original issue reported on code.google.com by bolinf...@gmail.com on 2 Jun 2010 at 1:42
The text was updated successfully, but these errors were encountered:
I think the information about which exact change was r584 was lost when this code was migrated from Google Code to GitHub, but we do still have the commit history including dates. Based on that, I think it was this change. The documentation could be improved, but based on JsonReader.setLenient we might guess that GsonBuilder.setLenient() is supposed to allow comments (as well as a bunch of other things). However as far as I can see comments are always enabled. Also see this test.
I don't think we can change this default leniency, but we could modify the documentation to describe the actual behaviour, and we could potentially add GsonBuilder.setLenient(boolean) to allow people to get strict parsing without using JsonReader directly.
we could potentially add GsonBuilder.setLenient(boolean)
That sounds like a good idea; it would allow fixing the whole issue that some methods of Gson cannot be made strict. However, the problem is that even in its current form JsonReader is not completely strict, see #1609.
So maybe a better solution would be (compared to introducing multiple strictness levels) to create config classes, e.g. JsonReaderConfig and JsonWriterConfig for which the user can individually enable and disable certain features. There could be two default instances then, STRICT (strictly follows the RFCs; would include #1609) and LENIENT (like the current lenient mode).
This would then for example also allow creating a strict JSONC (JSON with comments) reader.