On 11/21/2012 01:03 AM, Jörn Horstmann wrote:
The events in XMLEventReader are self-contained. Once you have the
event, you can get all the information from that event. For example,
using startElement event, we could get element name, attributes etc.
Here it is not the case. Also, people felt that this is not really a
* incremental processing of strings that are large. Some of you felt
this is useful.
I haven't yet come across Json data where streaming access to strings
would be required or give a big performance improvement. However, a
naive version of a getReader method would be really simple to
implement, while giving other
You also seem to indicate that this is not a common usecase. Then I
wouldn't want to consider it for this version.
Why do you prefer separate methods ?* We have a JIRA issue, that moves the cursor to certain place and
creates a corresponding
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
public <T extends JsonValue> T getJsonValue(Class<T> clazz)
I like the option to alternate between streaming and dom-based
parsing, but I would prefer distinct methods instead of one taking a
Maybe a better alternative for this usecase would be to extendThat seems like good alternative. Your suggestion is something like the
JsonReader so it could be constructed from a JsonParser and allow
reading of a partial stream.
JsonReader impl does this behind the scenes for the *full* stream. If
this is not a common use case, then we can defer it.
[jsr353-experts] Re: [json-processing-spec users] Re: Remaining work in JsonParser