[JSON_PROCESSING_SPEC-52] Make parsing location available to application code Created: 04/Feb/13  Updated: 08/Feb/13  Due: 08/Feb/13  Resolved: 08/Feb/13

Status: Resolved
Project: json-processing-spec
Component/s: None
Affects Version/s: 1.0-pr
Fix Version/s: 1.0-pfd

Type: Improvement Priority: Major
Reporter: jfuerth Assignee: jitu
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


The public review draft of the javax.json API does not make the parse location available to application code. Several members of the Toronto JUG indicated that this would be critically important to their adoption of the API.

It was suggested to create a Location type, and make location information available on request from JsonParser.getLocation(), and as a property of JsonParsingException.

Jitu pointed out that this was previously discussed on the mailing list. Here is that thread: http://java.net/projects/json-processing-spec/lists/users/archive/2012-11/message/61

Comment by jitu [ 05/Feb/13 ]

StAX had Location, but all the information is optional as per javadoc.

Are there any real usecases for JsonParser.getLocation() ?

One proposal could be to add only to JsonParsingException (not for JsonParser):

interface JsonLocation

{ int getLineNumber(); int getColumnNumber(); int getStreamOffset(); }

JsonParsingException(String message, JsonLocation location)
JsonParsingException(String message, Throwable cause, JsonLocation location)
JsonLocation getLocation()

Comment by jfuerth [ 05/Feb/13 ]

The JsonLocation interface you've proposed looks good.

I actually did ask one of the people who brought this up if it would be sufficient to put location information on the parsing exception only. He said no; he uses location information during his streaming XML parse, even when there are no syntax errors in the XML.

I don't know exactly what his use case is, but I can certainly imagine creating a system that throws an error when the data is semantically wrong. For example:

{ "id": 1234, "firstName": "Alice", "lastName": [1, 2, 3] }

although the above is a structurally valid JSON message, an application would likely want to reject it because lastName should be a string, but we were given an array. The application's own error message would be much better if it could include location information.

One final thought: unfortunately, we'll have to make location information optional too: when we are streaming a tree of JsonValues through JsonParser, there won't be an underlying character-oriented stream to calculate a line and column number from.

We could still require implementations to provide location information when the underlying data is coming from a string.

Comment by jitu [ 08/Feb/13 ]

Added JsonLocation as discussed

Generated at Thu Aug 25 12:49:57 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.