On 11/21/2012 09:26 PM, Jitendra Kotamraju wrote:OK, I will replace iterator() with hasNext/next methods. I will see if get any feedback on this.
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
At the moment JsonParser looks more like an Iterable than an iterator, even though it does not implement Iterable. We could add methods like `hasMoreEvents` and `nextEvent` directly to JsonParser and remove the `iterator` method. But these are just names, and since these two methods would behave like the methods from Iterator, which are short and familiar to developers, I think we should just name them `hasNext` and `next`.
It may require a revision during that time. That revision could be a MR (maintenance release) and has a much shorter life cycle. We need a few frameworks to layer on the current functionality and see what is really required.
* 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.
I'm okay with first providing a minimal version. As standards are moving rather slowly, do you think we will already need a revision of this spec when a Json-Binding JSR starts off?
Good point. So, only getJsonArray(), getJsonObject() (or different names as Tatu suggested) are really required methods. But building them using the builder is not that difficult for this usecase. May be, we can defer it.
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
I think with a getJsonValue(Class) method, its not exactly clear what the allowed parameters are. For example, can I call it with org.glassfish.jsonapi.JsonNumberImpl.class or my own class implementing any of these interfaces? Probably not, but the compiler will accept such code.
I don't think creating multiple JsonReader objects would be a problem. I just wonder whether we should add new constructors to JsonReader that take parser. We also need to define that JsonReader#close() doesn't close the parser in this case which is different from the other input sources that JsonReader is taking. So, I think it doesn't fit well there.
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.
I was thinking of additional constructors in JsonReader. Since it already contains a JsonParser instance it would be strange to pass another as a parameter. A downside would be that you'd have to create a new JsonReader per object or array to read, but JsonReader is a pretty light-weight class.
We should probably add both new constructors to JsonReader and get methods to JsonParser. Since JsonReader is part of the api package, it would not know about any specialized JsonValue implementations that a JsonParser impl could return. It might still be useful to create a standard dom tree from any JsonParser but defer the get-methods to a later version.
[json-processing-spec users] [jsr353-experts] Re: Re: Re: Remaining work in JsonParser