(note: issue to track this thread is
https://github.com/FasterXML/jackson3-dev/issues/5)
Jackson 3.x major version lets us do a few changes that minor version does not.
This includes both actual refactoring/-packaging of functionality, and
renaming, where beneficial.
In case of core streaming package (`jackson-core`), one long-term
issue is the historical precedence of json over all other formats.
This is due to Jackson starting as pure json processing package, and
other formats sort of only overriding pieces that differ: usually by
sub-classing actual full json implementation (as is case with
`JsonFactory`), or at least partial implementation (`JsonParser`,
`JsonGenerator`). Despite sub-optimal modeling this has actually
worked ok so far, from functionality perspective.
But although there is no burning acute problem with it, there are real
problems resulting from this modeling where there is no separation of
format-agnostic API and json implementation.
There have been occasional bugs where some format implementations have
not overridden all methods in `JsonFactory` (or `JsonParser`,
`JsonGenerator`) they should have, leading to odd bugs like CBOR
factory constructing json parser for certain input source.
With Jackson 3.x, then, one of first things should be cleaving out
JSON-implementation of the factory that constructs parsers (decoders)
and generators (encoders). This new abstraction needs name.
I think split itself is non-controversial, and although there is some
extra work at higher level (databind) with respect to change of
`JsonFactory` type to something else, I think changes are relatively
modest. At least compared to complexity of possibly renaming
`JsonParser`, `JsonGenerator`... but that's a different story, and
we'll burn that bridge once we get there.
This leaves actual naming.
I was initially thinking of factory producing encoders and coders --
codecs, in short -- leading to maybe `CodecFactory`. This could be bit
confusing due to existence of `ObjectCodec` abstraction, although I
don't know if that's a big deal.
But when I thought about this more, I realized that it is perhaps
better consider it a "stream factory", constructing stream readers
(parsers) and writers (generators).
So, my leading name candidate is actually:
StreamFactory
which would then lead to implementations like SmileStreamFactory (or
SmileFactory?), Avro[StreamFactory] and so forth.
It would even be possible to retain `JsonFactory` as actual
Json-backed implementation, although I am not sure if that would help
or hinder upgrade from 2.x, since semantics of the class would be
somewhat different.
So: I have really 2 questions:
1. What should be name of the new low-level stream factory class:
(a) StreamFactory, or
(b) CodecFactory, or
(c) something else (and if so, what)
2. Should implementations use short or long form:
(a) Short form: JsonFactory, SmileFactory
(b) Long form: JsonStreamFactory, SmileStreamFactory
and my default choice would be:
StreamFactory
JsonStreamFactory extends StreamFactory
AvroStreamFactory extends StreamFactory
Please let me know what you think; suggestions, comments, other
feedback welcome.
-+ Tatu +-
ps. A follow-up issue
(https://github.com/FasterXML/jackson3-dev/issues/8) deals with
changes to actual construction, configuration of these factories, for
any interested in what comes next wrt Streaming API
--
You received this message because you are subscribed to the Google Groups
"jackson-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
