My preference would be for 4, interfaces and factories for all parts of the api, leaving the interaction between these classes to the implementation. There would also be no model implementations inside the api module.Let us put that as an option 5. Remove pluggability. No JsonParserFactory, JsonGeneratorFactory, and Json. Make JsonParser, JsonGenerator as classes
The idea behind making JsonParser and interface was to allow switching to a more performant parser. If this performance benefit is negated by the neccessary lookup code, and additional factories are seen as too complicated, then maybe another option would be to remove this pluggability and make everything part of the api module. The model classes could then also be truly immutable final classes.
But such a decision requires more discussion from eg members and possible implementors.
On 01/11/2013 08:49 PM, Jitendra Kotamraju wrote:
I think we have quite a bit of discussion on this in the mailing lists.
The issue has all the pointers of discussion. Let me summarize the
1. Leave as it is. Developers would be using new JsonReader(), new
JsonWriter(), new JsonObjectBuilder()/new JsonArrayBuilder(). An
implementation detail is to implement caching of provider in the API.
2. JsonReader/JsonWriter will have additional constructors that take
3. Introduce JsonReaderFactory/JsonWriterFactory and make
JsonReader/JsonWriter as interfaces.
Also Json.createReader(), Json.createWriter() for common cases. But we
need to see how this works out with Json class as it may become
4. Option 3 + Json.createObjectBuilder() and Json.createArrayBuilder()
(may be factories for them as well).
5. Any ??
Let us resolve this issue soon as it may involve many changes.
[jsr353-experts] Re: [json-processing-spec users] Re: JSON_PROCESSING_SPEC-40: JsonBuilder and JsonReader should be interfaces