Improve lenient mode documentation #2122
Conversation
| * read is strict. Create a {@link JsonReader#setLenient(boolean) lenient} | ||
| * {@code JsonReader} and call {@link #read(JsonReader)} for lenient reading. | ||
| * | ||
| * <p>No exception is thrown if the JSON data has multiple top-level JSON elements, |
There was a problem hiding this comment.
This behavior is probably rather questionable though...
| * prefix</a>, <code>")]}'\n"</code>. | ||
| * <li>Streams that include multiple top-level values. With strict parsing, | ||
| * each stream must contain exactly one top-level value. | ||
| * <li>Top-level values of any type. With strict parsing, the top-level |
There was a problem hiding this comment.
This and the changes below in this file are based on #1609 and the comments there.
This specific sentence was outdated because Gson already supports top-level values of other types, even in strict mode.
| * <li>Name/value pairs separated by {@code ;} instead of {@code ,}. | ||
| * </ul> | ||
| * | ||
| * <p>Note: Even in strict mode there are slight derivations from the JSON |
There was a problem hiding this comment.
Maybe this should clarify that these derivations are not guaranteed behavior and might change in the future?
0452999 to
cbd2f84
Compare
|
Thanks for doing this! I'm merging as-is, but feel free to convert some of the open questions into other PRs or new issues. |
|
Thanks for merging this!
The main open problem is probably the missing end of document check for the |
Fixes #1720
Resolves #1923
Relates to: #372, #763, #1208, #1609
Improves the documentation regarding lenient mode and trailing data handling. The current Gson behavior is still not ideal, but now at least the documentation (hopefully) matches the actual behavior.