On Tue, Nov 20, 2012 at 10:44 PM, Jitendra KotamrajuIf it is not a common case, then perhaps we don't have to add it to the API.
I am working on incorporating the all the discussed changes and make a draftRight -- not so much for performance, but for scalability and low
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
latency when dealing with CLOBs/BLOBs. Not a very common case, but
something I have used myself and that has been requested.
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 ?
* skipValue()Not only convenience actually -- as others mentioned, for performance,
This is primarily a convenience method and can be implemented using other
methods. So should we consdier this ?
since this can avoid most of object allocations, and (when properly
implemented) even byte->char decoding.This could be true.
Good point about advancing the stream. We can work on different name.
* We have a JIRA issue, that moves the cursor to certain place and creates aSince these are not exactly regular getters, maybe some other names
getJsonValue(JsonObject.class) is valid in START_OBJECT state, moves cursor
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
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.
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.
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 +-
[json-processing-spec users] Re: Remaining work in JsonParser