[json-processing-spec users] Re: Remaining work in JsonParser
- From: Tatu Saloranta <
- Subject: [json-processing-spec users] Re: Remaining work in JsonParser
- Date: Wed, 21 Nov 2012 11:32:10 -0800
On Tue, Nov 20, 2012 at 10:44 PM, Jitendra Kotamraju
> 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
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.
> * 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
implemented) even byte->char decoding.
> * We have a JIRA issue, that moves the cursor to certain place and creates a
> 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
> 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.
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 --
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.
-+ Tatu +-