[json-processing-spec users] Re: [jsr353-experts] Java SE 7 as the base
- From: Tatu Saloranta <
- Cc: Eugen Cepoi <
- Subject: [json-processing-spec users] Re: [jsr353-experts] Java SE 7 as the base
- Date: Tue, 9 Oct 2012 17:24:16 -0700
On Tue, Oct 9, 2012 at 3:05 PM, Jitendra Kotamraju
> On 10/08/2012 01:18 PM, Eugen Cepoi wrote:
> I agree with Tatu, autocloseable will prevent existing libraries to
> implement the spec.
> In addition I think it would be useful to implement Flushable in
> JsonGenerator and JsonWriter.
> It would allow libraries implementing the spec to use some optimization
> mechanisms such as
> internal buffers for small inputs.
> I think that JsonGenerator can extend Flushable. Is there a use for
> JsonWriter to implement Flushable and when does an application call flush()
> method ? Fo e.g.
> JsonWriter w = new JsonWriter()
> // At this time there is not much use in calling flush(), instead close()
> can be called.
I agree there -- for JsonGenerator it is useful, and there are cases
where it is essential (for long data stream over network, where one
must be able to push data without closing stream) -- but for higher
level maybe not?
> I also think that JsonWriter and others should close the underlying
> output/input sources(I changed my position). That would be similar to other
> readers/writers in JDK so that chaining would work better. Initially, I was
> thinking that writing JSON in one MIME part shouldn't close the whole output
> stream where other parts would be writtern. But that's not that common when
> compared to usual closing of the stream.
I have had to support both modes, auto-close being default. I think
auto-close is probably more common, but then again there are cases
where callers do NOT want auto-closing; this is something that JAX-RS
implementations tend to do.
While one can use OutputStream wrappers, it's extra work that API
So I would actually consider this as possible second standard feature
to define, with sensible default setting (auto-close enabled).
-+ Tatu +-