Some further thoughts on this. I did a poll on Twitter, with results of:
* 89%: Go with Java8 * 11%: Stick to Java6 runtime compatibility (with 57 answers). which sort of confirmed my hunch on what the general feeling would be. This in itself wasn't news, but at least provided some support for some desire of backwards compatibility. But more useful were comments; especially one by Olivier G, who suggested that this is a Major change, and should be reflected by changing version to Jackson 3.0. My gut reaction was "hell no!", but I started meta-thinking as to why so. This lead back to Jackson 1.9 -> 2.0 upgrade, and how that was done; I realized that I feel strongly that this is not what should be done now. The problem here is that while I consider Jackson 1.x -> 2.0 upgrade a success in many way -- it has avoided some of nastiest compatibility problems due to namespacing -- it has lead to fragmentation, such that perhaps 1/4 or 1/3 of all Jackson usage is still with old Jackson 1.x, which hasn't been maintained for years. But at least with 2.0, there were many things I wanted to change in API, some in behavior, so that such abrupt change had certain benefits. I do not feel we are in same situation with 2.x yet. Further, fragmenting usage once more would in all likelihood result in even slower adoption of Jackson 3. However. Doing 3.0 the way 2.0 was done. Many libraries do very little in way of changes, and "major" version upgrade is more of a "Marketing Major", chosen to imply something totally new and better, but with little to no compatibility change. I tend to dislike this approach in general, but in this particular case perhaps it would be a reasonable thing to do: while API itself is compatible (at level of regular minor version upgdade), platform requirements are different, so from user perspective change may be big -- it is trivial, if already on Java 8, but major if not. So.... there's this possibility, that we would boost major version, but NOT change either Maven group id or Java package name(s). We could make some other slightly more breaking changes to things like defaults; and removal of deprecated parts of public API (instead of only internal APIs, from which deprecated methods are and will be removed over time, even in minor releases). But for the most part we'd have to minimize compatibility changes, since there would be no namespace isolation. WDYT? -+ Tatu +- On Mon, Sep 26, 2016 at 9:32 PM, Tatu Saloranta <[email protected]> wrote: > After slow gradual upgrades to JDK baseline, I think time may have come to > move to Java 8 for Jackson 2.9. But before committing to this course, I > want to make sure there is wide agreement on this, as well as on mitigation > plans for users who can not use the new version. > > My thinking here is that moving to Java 8 is mostly beneficial, first, in > simplifying use of 3 commonly used add-on modules: > > 1. jackson-module-parameter-names: Small modules that allows > introspection of creator (constructor, static factory method) parameter > names. Easy to just embed > 2. jackson-datatype-jdk8: Optional and related types. Medium-size, > probably easiest to just directly embed > 3. jackson-datatype-jsr310: Java 8 date/time -- big module, need to figure > out if to embed, or to add dependency + auto-registration > > Use of Java 8 language features would also be nice but I am not yet sure > how to proceed with API changes. It may make sense to first add support for > JDK 8 types, and then target API improvements (and implementation usage) > for later. > > If this change is made, I think we would want to keep 2.8 branch open for > longer than most other minor branches. > This would probably be most relevant for Android (as usual :), although we > could also consider advocating use of jackson-jr more as an alternative > that has some benefits for Android as well -- and it will remain Java 6 > compatible for foreseeable future. > I have also read articles about Android moving towards Java 8 as well so > maybe it's just a question of timing. > > At any rate: first things first -- anyone against raising Jackson 2.9 > baseline to be Java 8? (if not, there are follow-up aspects to discuss, > esp. wrt Java 8 datatype module). > > -+ 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.
