Error message position fixes

[johnjaylward]

Key Changes:

• Fix error message position information to be accurate

What problem does this code solve?
Corrects incorrect position information when generating syntax errors in tokeners.

Risks
None. The current position information is wildly off in some cases. It's not helpful to anyone trying to debug a failing document.

Changes to the API?
none.

Will this require a new release?
Yes, this is a bug fix that should probably be corrected as soon as possible

Should the documentation be updated?
No

Does it break the unit tests?
Yes. The current position information in the XML error messages is wrong/inaccurate. The changes here in regards to the JSONTokener.more function have fixed many of the position problems in the old code. Some other pieces of code needed to be updated as well.

See the corrected tests here: stleary/JSON-Java-unit-test#74

Was any code refactored in this commit?
Yes. The JSONToken.more function was changed to use the mark/reset support in the stream reader instead of stepping forward and backward. This gives us faster checking on more() as well as more accurate position information as we aren't moving our index around every time we want to see if there is more information in the stream.

Also, a new field characterPreviousLine was added to track the previous line's character count in order to preserve character information when stepping back at a new line mark.

Review status
ACCEPTED, starting 3 day comment window.

[johnjaylward]

@stleary any chance to review this yet? No rush (I know it's holiday time for US and Canada), just wanted to make sure it wasn't missed or forgotten.

[stleary]

Thanks for the reminder, holidays and weekends are actually the source for a lot of my free time :) Agree the bug fix should be committed. Any chance you can separate that code from the formatting changes?
Per the FAQ, code formatting changes are normally not accepted. I was trying to make an exception in this case, but as you noted, no progress has been made.

[johnjaylward]

sure, I think I can just revert that one commit

[johnjaylward]

the revert was clean. Should just be these changes now.

[stleary]

Thanks for backing out the reformatting changes.

[johnjaylward]

no problem. If possible though, I would like the code to be more consistent. Right now the mixed spaces/tabs and the inconsistent indentation make it harder to contribute. If we could settle on something then reformat to match, that would be very helpful.

[johnjaylward]

@stleary also, I'm wondering if I should back out some of the recent changes I made that make it even harder for Android compatibility before doing a release. Not all the change in #350 , but specifically the ones for entrySet and maybe some others I can't think of off the top of my head. Or should we just wait for #350 to get tested and merged before worrying about android?

It does looks like my change to the Android JSONException class are getting added to Android Master soon, but still no guarantee that it will be released in a timely fashion for Android Developers to use.

[stleary]

Sure! How does indent 4 spaces, no tabs sound? A commit that contains only formatting changes for one or more files, and passes unit tests, would be fine.

[stleary]

It seems to me that an actual Android developer who uses JSON-Java is needed to Beta test #350, and then recommend approval or further changes.