Now that 2.9.0 has been released it is time to start work for Jackson 3.0.
I have written earlier about my thoughts and plans, and I will try to
present my current thinking on subject. Although I will try to keep
this note self-contained it may help to check archives for my earlier
postings.
This will be somewhat lengthy dumping of my current thinking. So I'll
start with short(er) TL;DNR section, followed by longer full
explanation.
So what I plan on doing now:
- Create new `3.0` branch, keep `master` for `2.9` initially, possibly
for months.
- Create new github repo to contain 3.0 non-compatibility changes, wiki
- Immediate work: remove all 2.x deprecated functionality; change JDK
baseline to Java 8
- Very-soon-now work:
- Integrate some of Java 8 features (parameter names, Optional
support) in databind
- Remove format auto-detection support
- Remove ability to change `JsonFactory` configured for `ObjectMapper`
- For other work, track via new tracker, mailing lists (with refs to issues)
- Removal of major and minor functionality, modules
- Change of default settings (mostly Features), behavior
And here's longer explanation of my thinking.
---- Full info dump on above ---
1. Challenges between 2.9 and 3.0 development, wrt codebase
Unlike new minor releases, for which working process is well
established by now (after official .0 release, a new maintenance
branch is created for that minor version, and `master` is updated for
work towards next minor version), there is less precedence for major
upgrade.
Last time we moved everything over from Codehaus/SVN to github and
renamed all Maven and Java packages (but not classes). This time we
will probably not do the same since I have a feeling that doing this
would be detrimental for project, balkanizing usage. But I also think
there is less need for such move. Details are up to discussion, still.
With that, I think the main difference between 1.9 -> 2.0 and 2.9 ->
3.0 is simply that in former case 1.x branch was not worked on much at
all; switch was swift and complete.
But with 2.9 I think there will be longer maintenance cycle, and there
will be non-trivial period of time during which 2.9.x gets significant
bug fixes.
During much of this time there will, then, be need to merge fixes
between versions. This is easiest done when there is no repository
migration, nor Java package name changes.
So what I plan to do on short term is to create new 3.0 branches for
`jackson-core` and `jackson-databind` (but not initially for
`jackson-annotations`) -- and for other modules on as-needed basis.
`master` branch, however, would remain as 2.9.x initially, to allow
bit more experimentation with 3.0.
In a way this is just a minor detail of course; merges between two
branches are needed initially; but after certain point it may be that
versions drift too far for easy merging. We'll see.
After things with 3.0 progress far enough it will be time to create
`2.9` maintenance branch, switch `master` to 3.0. But this will
probably take months.
2. Challenges: issue tracking
One thing that will probably be bit confusing is that of issue
tracking. I have included some `3.x` issues within current repository,
but although this could in theory be continued I think this could
become confusing quite quickly.
So what I am thinking is that I should create one new
"issues-and-wiki-only" github repo for containing issues for:
a. Proposed new features, changes, grouped in some suitable form: this
allows discussions
b. Active work from (a) where there is decision to proceed (via
consensus or by Benevolent Dictator)
for all Jackson components, wrt. 2.9 -> 3.0, related to compatibility changes.
This has one issue of its own (issue ids between repos are not
unique). But I think that as one-time tracking of major changes
between versions this will work as simple namespacing.
And once 3.0 changes are (mostly?) wrapped we can go back to using
main issue tracker.
For what it's worth I have included preliminary issue thoughts here:
https://github.com/FasterXML/jackson-future-ideas/wiki/Jackson3-Changes
Note: although issues should be the primary audit trail for changes I
think mailing list is still needed for some of discussion.
3. Initial work, preparing for 3.0
I think there are couple of things that can and should be done
immediately, since they are sort of reasons for major version:
- Java 8 upgrade: use of language features, warnings removal
o possibly integrate smaller pieces of Java 8 modules (Optional
types, parameter names)
- Immediate removal of all deprecated methods, fields, classes (and in
general functionality) marked as @deprecated during 2.x cycles --
including public API retained so far (internal API has often been
deprecated at faster cycle)
Of deprecated functionality biggest full feature is the "old JSON
Schema" support: it has been marked as deprecated since ~2.4, and
replacement that uses visitor methods has been fully functional since
then as well. I don't think this change is controversial
4. Planned feature deprecation
As per https://github.com/FasterXML/jackson-future-ideas/wiki/Jackson3-Changes
there are certain other 2.x features that I think should be removed from 3.0.
4.1 DataFormat detection (JsonFactory, ObjectMapper)
One of features for which I had high hopes is the ability to ask
`JsonFactory` or `ObjectMapper` to figure out format from a set of
alternatives. This worked beautifully with first 3 formats -- json,
Smile, XML -- but it turns out that many other formats have been
designed in a way that does not allow detection (looking at you
protobuf, avro). But there are also problems in figuring out how to
make this feature work nicely with modularity of mapper instances as
well.
(in fact, removing of this would also help with the other deprecation
item; ability to change `JsonFactory`).
But beyond my own misgivings, I just don't think this feature is
widely used; and thereby also not widely tested either for usability
or full reliability.
So: I think that ability to do automatic format-detection should be
removed from the API.
Individual factories may still choose to retain low-level detection
functionality in some form, as this would allow users to construct
detectors; and/or create a module that does this.
This approach should lead to better API as well.
4.2 Ability to change JsonFactory of ObjectMapper
One problem with interaction between `ObjectMapper` (and -Reader,
-Writer) and `JsonFactory` is the fact that although most if not all
usage just creates mapper with a factory and never changes it, mapper
does allow changing of factory.
Mostly this is to (I think) to support format-detection (see above);
or perhaps to allow late binding of format.
And why is this a problem? Because although there is clean separation
between databinding and streaming API (with exception of XML....) with
respect to layering, there are actual runtime dependencies --
serializers/deserializers constructed for specific formats DO actually
differ.
Or would like to differentiate processing for performance reasons, but
can only do so in very dynamic way, checking for format features for
every call (because determining features during construction
guarantees nothing about actual usage).
Eliminating ability to change would in particular help implementations
of binary formats that require schemas (like protobuf, avro), but it
could also simplify handling of other (de)serializers.
5. Possible feature deprecation
5.1 Serializability (java.io.Serializable) of Jackson components
During 2.x cycle one feature added was ability to JDK serialize
`ObjectMapper` and things it references. This was to support some use
case on Android platform where freezing/thawing of mapper instances
was faster than re-creating it.
The main problem here is two-fold:
(a) In most cases this is fundamentally misguided approach: mapper (et
al) is a dynamic instance and quite often it is not meant to be
transferred over -- and in fact knowing it is not be serialized is a
good hint at... well, not trying to do it. For example in streaming
data processing you really should serialize data, and not processing
components -- or if you do, latter should be done in a way where only
configuration is passed
(b) Cost of supporting this functionality is non-trivial: amount of
code is not huge, but number of classes with need for some code is
surprisingly large
Now: I would rather try to support an alternative where there was a
way to figure out how to serialize configuration of `ObjectMapper`
(`ObjectReader`, `ObjectWriter`). But that may be challenge of its
own, mostly due to extension modules.
I have not made up my mind here, and I have heard at least one
developer express wish to retain this ability.
6. Module deprecated
Due to various challenges, consider deprecating formerly (2.x)
supported modules:
- Hibernate: no one owning the module -- shame, but this has code-rotten
- JSON Schema: only supports v4, no owner, better alternatives outside
Other ones at risk:
- Scala module is bit on-and-off, but seems to get enough support, and
be widely used that should try to keep it afloat.
7. Other planned work:
- Change of various `XxxFeature` defaults (in some cases removing
feature, if only supported legacy settings)
-+ Tatu +-
--
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.
