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.
Zitat von 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()
The method names in the iterator interface are short and intuitive, but I would suggest that JsonParser should directly implement iterator instead of providing an iterator() method. This should make it clear that the event stream is not restartable and that the parser and iterator methods are closely related. I think this is also the approach used in the javax.xml.stream.XMLEventReader interface.
* 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
JsonParser implementation the opportunity to create better performing versions.Yes, that's true. As I asked in other mail, I want to understand object allocation angle.
May be used for performance. I don't want to consider other match methods that match both name and value
I did not follow the discussion on matchName that closely, so the other experts have to comment on this one.
This is primarily a convenience method and can be implemented using other methods. So should we consdier this ?
I think this might be useful as a method of JsonParser since its implementation could avoid most object allocation. An utility method in another class would not have that option. A simple implementation could still delegate to the other parser methods so it isn't to difficult to implement.
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 Class parameter.
That seems like good alternative. Your suggestion is something like the following:
Maybe a better alternative for this usecase would be to extend JsonReader so it could be constructed from a JsonParser and allow reading of a partial stream.
[json-processing-spec users] [jsr353-experts] Re: Re: Remaining work in JsonParser