Should support SAX like function? about gson HOT 8 CLOSED

Just a suggestion: make it "pull" variety (~= stax), since it is trivial to 
invert
Stax to produce SAX-like events (so "SAX" part can build on lower-level "Stax" 
part).
The reverse is not generally possible without multi-threading (or language 
support
for co-procedures/closures).

Would this be served by providing a hook to plug-in a different JSON parser? 

Can you give us some concrete examples of where this will be useful? You can use
custom serializer/deserializers to do the customized handling anyway. But you 
are
right, our parser creates the parse tree first, so can choke on very large 
input. 

http://www.cowtowncoder.com/hatchery/jackson/index.html

I am using JSON-lib and looking for a better one. I myself like upper lib so far
since it supply a Streaming API which allows to process huge data. But then I 
found
your lib, which is also a nice one expect do not support Streaming API. I think 
which
would be a highlight if you can add it in.

When I said customize the parsing, I mean you could supply event like SAX do, 
so I
can create new instance or set value according to the events. 

I do not how to do these because I do not know parsing algorithm. But I wish to
supply some idea to make gson better.

Thanks,

Jiming

We thought more about it, and it seems that this is worth doing since it will 
enable
Gson to process really large documents. We will essentially have to rewrite our
parser to either support SAX (event based) or StAX (Streaming based) parsing. 
This
can probably be done by modifying our JavaCC grammar itself. This is a major
undertaking, but we will consider this for one of our major releases. 

Great to hear that!

Thanks and looking forward to that.

Jiming

Hi I just ran into this issue as well.  Any timeline for when issue 28 will be 
addressed?

Well, I looked into rewriting our JavaCC parser to be a SAX or pull-based one, 
and 
was not terribly successful. At this time, we have put this on hold. If someone 
can 
point us to a third-party SAX/pull parser that we can adapt, we will consider 
using 
it. Or better, help us write one. 

This will likely have an impact on the backward compatibility. However, that is 
something we can carefully weigh on.

We dont have SAX like functions, but Gson 1.4 adds a JsonParserAsync class that 
lets 
you parse multiple JSON objects on a stream. 

Overall, backwards compatibility is quite important for us, so I dont see us 
breaking 
that in favor of a SAX like parser (which is in general harder to use).