Skip to main content

[json-processing-spec users] Re: Remaining work in JsonParser

  • From: Jitendra Kotamraju < >
  • To:
  • Subject: [json-processing-spec users] Re: Remaining work in JsonParser
  • Date: Wed, 21 Nov 2012 12:08:28 -0800

On 11/21/2012 11:32 AM, Tatu Saloranta wrote:
On Tue, Nov 20, 2012 at 10:44 PM, Jitendra Kotamraju
< >
 wrote:
I am working on incorporating the all the discussed changes and make a draft
ready for public review phase. In the meantime, I want to make some progress
on the JsonParser changes that were discussed in various threads. Let me
know if we want to consider any of these.

* iterator() gives iterator of events. But these events are *not*
self-contained items like Map.Entry, so that looks odd to call some methods
on parser object and some methods on iterator object.
Since this more of cursor API (rather than iterator), should we consider two
separate methods ?

boolean advance() instead of hasNext()
Event getEvent() instead of next()

* incremental processing of strings that are large. Some of you felt this is
useful.
Right -- not so much for performance, but for scalability and low
latency when dealing with CLOBs/BLOBs. Not a very common case, but
something I have used myself and that has been requested.
If it is not a common case, then perhaps we don't have to add it to the API.

* skipValue()
This is primarily a convenience method and can be implemented using other
methods. So should we consdier this ?
Not only convenience actually -- as others mentioned, for performance,
since this can avoid most of object allocations, and (when properly
Even otherwise, there won't be object allocations since getString()/getNumber() methods are not called. You would be skipping the event states, say START_ARRAY to END_ARRAY, so there won't be intermediate objects. Of course, it depends on impl, but am I missing anything ?
implemented) even byte->char decoding.
This could be true.


* We have a JIRA issue, that moves the cursor to certain place and creates a
corresponding
JsonValue

/*
getJsonValue(JsonObject.class) is valid in START_OBJECT state, moves cursor
to END_OBJECT
getJsonValue(JsonArray.class) is valid in START_ARRAY state, moves cursor to
END_ARRAY
getJsonValue(JsonString.class) is valid in VALUE_STRING state
getJsonValue(JsonNumber.class) is valid in VALUE_NUMBER state
and other values
*/
Since these are not exactly regular getters, maybe some other names
would be better. Not sure what, but something like "nextValue()" (or
decode/build/parse/collectValue) would indicate that it actively
advances stream. I know that Stax used "getElementText()", but that
lead to quite a bit confusion for
novice users who thought it'd be DOM style, and not affect the stream.
Good point about advancing the stream. We can work on different name.
But in general, do you see the need to put in the API or a developer
can build it using JsonBuilder ?


One more thing: is there no way to access Location information? This
is important for error messages; not just ones parser/reader throws a
exceptions, but for calling code, when indicating validation problems.
This should give access to row/column numbers and perhaps source --
see
Stax for examples.
This is an area that many parsers skimp on, but there's nothing more
frustrating than trying to track down a validity issue in
multi-megabyte file, without having good location information.
I would think location information is useful. Others had concern whether it would be easy to determine and implement row/column numbers for a stream. I wouldn't suggest any test in TCK for this.

In general, if a feature is not used that much, I don't want to put in API esp. first version.

Jitu

-+ Tatu +-



[json-processing-spec users] Remaining work in JsonParser

Jitendra Kotamraju 11/21/2012

[json-processing-spec users] [jsr353-experts] Re: Remaining work in JsonParser

Jörn Horstmann 11/21/2012

[json-processing-spec users] [jsr353-experts] Re: Re: Remaining work in JsonParser

Jitendra Kotamraju 11/21/2012

[json-processing-spec users] [jsr353-experts] Re: Re: Remaining work in JsonParser

Jörn Horstmann 11/21/2012

[json-processing-spec users] [jsr353-experts] Re: Re: Re: Remaining work in JsonParser

Jitendra Kotamraju 11/26/2012

[json-processing-spec users] Re: Remaining work in JsonParser

Eugen Cepoi 11/21/2012

[json-processing-spec users] Re: Remaining work in JsonParser

Tatu Saloranta 11/21/2012

[json-processing-spec users] Re: Remaining work in JsonParser

Jitendra Kotamraju 11/21/2012

[json-processing-spec users] Re: Remaining work in JsonParser

Tatu Saloranta 11/21/2012

[json-processing-spec users] Re: Remaining work in JsonParser

Jitendra Kotamraju 11/26/2012
 
 
Close
loading
Please Confirm
Close