Will 3.0 only be Java 8 baseline or will it also include Java 8 Jackson features?
On Saturday, October 8, 2016 at 1:51:18 AM UTC+3, Tatu Saloranta wrote: > > Ah ok. Just wanted to make sure as it makes a big difference. :) > > There would still be room for plenty of discussion on exact changes to > make, limits and so on. > > -+ Tatu +- > > > On Tue, Oct 4, 2016 at 10:39 PM, Christopher Currie <[email protected] > <javascript:>> wrote: > >> Sorry, editing mistake, that should have been *not* necessary, and in >> fact not desired. StringTemplate 4 changed co-ordinates as a patch release >> (from 4.0.2 to 4.0.3) causing headaches in class paths and eventually >> needing to use the dependency plugin's "banned dependencies" feature. >> >> >> >> On Tue, Oct 4, 2016 at 10:14 PM Tatu Saloranta <[email protected] >> <javascript:>> wrote: >> >>> On Tue, Oct 4, 2016 at 6:53 PM, Christopher Currie <[email protected] >>> <javascript:>> wrote: >>> >>>> I think that if Jackson doesn't take the opportunity to cull the dead >>>> API weight at version 3, it will never happen. I support the proposal to >>>> make the Java 8 update in version 3, and shed the API as needed. I also >>>> agree that changing the Maven co-ordinates is necessary. >>>> >>> >>> I was actually thinking & suggesting not changing Maven co-ordinates, >>> due to that significantly slowing uptake of 3.x. As of now, Jackson 2.x is >>> only about 2x as widely used as 1.x, after 4 years. >>> >>> Question of Maven coordinates is tied to the question of Java package as >>> well. If only Maven group id was changed, upgrade could still be simple -- >>> only pom change needed. The big difference is with Java package, as >>> changing that will require sizable (if very mechnical, at least with 1.x -> >>> 2.x) changes. >>> >>> But if only changing Maven coordinates, there's the nasty possibility of >>> classpath clashes; in fact, this can be worse than not changing Maven >>> package. So I guess it's both Maven and Java package, or neither. Just one >>> does not make as much sense. >>> >>> Anyway. I don't feel huge need to make drastic API changes so it is >>> quite possible to go 3.0 but only really base that on JDK baseline change, >>> and not on public API change. That is one of options. >>> >>> -+ Tatu +- >>> >>> >>> >>>> >>>> Christopher >>>> >>>> On Tue, Oct 4, 2016 at 10:22 AM Tatu Saloranta <[email protected] >>>> <javascript:>> wrote: >>>> >>>>> Based on feedback, I think that going Java 8 should indeed be >>>>> signalled with major version upgrade. >>>>> But unlike with 1.x -> 2.x, I think this can and should be done >>>>> without changing Maven/Java-package coordinates. This would allow >>>>> behavior >>>>> similar to minor-version update for users who are already on Java 8 >>>>> (which >>>>> I suspect is vast majority); but signal other users that there is >>>>> something >>>>> of _potential_ compatibility problem. >>>>> >>>>> Now: from that point, we have two choices wrt API changes: >>>>> >>>>> 1. Consider 2.9 -> 3.0 a minor change, and keep even @deprecated >>>>> public API (internal, non-public api is not guaranteed to stay with minor >>>>> releases, but we try to give at least one minor version grace-period for >>>>> those) >>>>> 2. Take the opportunity to do little more changes. Most likely: >>>>> - Remove deprecated (at least by 2.8) public methods -- there are >>>>> some that date back to 2.0, esp. in `JsonFactory` >>>>> - Change some of the defaults. For example: >>>>> o Seems like majority of users prefer >>>>> `FAIL_ON_UNKNOWN_PROPERTIES` to be `false` (1.x and 2.x have it as `true`) >>>>> - Make minor changes to public API that really make sense (that is, >>>>> similar to bug fix) but that are not binary or source compatible; mostly >>>>> to >>>>> Tree Model (JsonNode): >>>>> o Existing `void` methods that ought to be chainable; add >>>>> `this` return type >>>>> o Existing methods that do not declare exceptions but should: >>>>> some JsonNode methods >>>>> >>>>> My personal leanings would be towards (2), with some or all of >>>>> proposed changes; but I do not assume all users agree. Resulting breakage >>>>> is nasty if you are hit by it; especially so for transitive dependencies. >>>>> >>>>> Now: if and when 2.9 will proceed with Java 7, no changes would be >>>>> made until end of the year (that is, at earliest january 2017 for >>>>> master). >>>>> But I would create a Wiki page to collect plans for changes to make, so >>>>> that for once these may be discussed a priori. I also plan to send update >>>>> summaries when significant changes/additions are made. >>>>> >>>>> Thoughts? >>>>> >>>>> -+ Tatu +- >>>>> >>>>> ps. Anyone with insight on Android's Java 8 plans would be very >>>>> welcome to share those. >>>>> >>>>> >>>>> -- >>>>> 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] <javascript:>. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>>> 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] <javascript:>. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >>> 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] <javascript:>. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> 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] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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.
