Skip to main content

[json-processing-spec users] Re: [jsr353-experts] Java SE 7 as the base

  • From: Tatu Saloranta < >
  • To:
  • 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
< >
 wrote:
> On 10/08/2012 01:18 PM, Eugen Cepoi wrote:
>
> Hi,
>
> 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()
> w.write(obj)
> // 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
could eliminated.

So I would actually consider this as possible second standard feature
to define, with sensible default setting (auto-close enabled).

-+ Tatu +-


[json-processing-spec users] [jsr353-experts] Java SE 7 as the base

Jitendra Kotamraju 10/08/2012

[json-processing-spec users] Re: [jsr353-experts] Java SE 7 as the base

Tatu Saloranta 10/08/2012

[json-processing-spec users] Re: [jsr353-experts] Java SE 7 as the base

Eugen Cepoi 10/08/2012

[json-processing-spec users] Re: [jsr353-experts] Java SE 7 as the base

Jitendra Kotamraju 10/09/2012

[json-processing-spec users] Re: [jsr353-experts] Java SE 7 as the base

Tatu Saloranta 10/10/2012

[json-processing-spec users] Re: [jsr353-experts] Java SE 7 as the base

Jitendra Kotamraju 10/17/2012

[json-processing-spec users] [jsr353-experts] Re: Java SE 7 as the base

Jörn Horstmann 10/10/2012

Message not available

[json-processing-spec users] [jsr353-experts] Re: Java SE 7 as the base

Sagara Gunathunga 10/10/2012

[json-processing-spec users] Re: [jsr353-experts] Re: Java SE 7 as the base

Eugen Cepoi 10/10/2012

[json-processing-spec users] Re: [jsr353-experts] Re: Java SE 7 as the base

Jitendra Kotamraju 10/10/2012

[json-processing-spec users] Re: [jsr353-experts] Re: Java SE 7 as the base

Eugen Cepoi 10/10/2012

[json-processing-spec users] Re: [jsr353-experts] Re: Java SE 7 as the base

Eugen Cepoi 10/10/2012

[json-processing-spec users] Re: [jsr353-experts] Re: Java SE 7 as the base

Jitendra Kotamraju 10/11/2012

[json-processing-spec users] Re: [jsr353-experts] Re: Java SE 7 as the base

Jitendra Kotamraju 10/11/2012

[json-processing-spec users] Re: [jsr353-experts] Re: Java SE 7 as the base

Eugen Cepoi 10/13/2012
 
 
Close
loading
Please Confirm
Close