Ok, I agree. Regarding parameter names, in 3.0.0 I suggest that the default behaviour for single param constructors (delegating creator) changes so we can cover everything with parameter names by default.
Regarding Java 8 time, in 3.0.0 I suggest that this should be aligned with Date behaviour regarding ISO-8601 handling (offset/timezone) - https://github.com/FasterXML/jackson-datatype-jsr310/issues/79. Current behaviour is inconsistent with Date behaviour. On Friday, October 14, 2016 at 9:11:41 PM UTC+2, Tatu Saloranta wrote: > > It should support language features (parameter names) for sure. > I think it should support optional types as well, relatively small. > > And despite the additional size, yes, I think it should also support full > Java8 date/time value type set. > > So we could simplify the long-running discussion on best way to support > Java 8 features. > > -+ Tatu +- > > > On Fri, Oct 14, 2016 at 8:02 AM, Lovro Pandzic <lovro....@gmail.com > <javascript:>> wrote: > >> 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 <ch...@fasterxml.com >>> > 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 <ta...@fasterxml.com> >>>> wrote: >>>> >>>>> On Tue, Oct 4, 2016 at 6:53 PM, Christopher Currie < >>>>> chris...@currie.com> 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 <ta...@fasterxml.com> >>>>>> 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 jackson-dev...@googlegroups.com. >>>>>>> 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 jackson-dev...@googlegroups.com. >>>>>> 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 jackson-dev...@googlegroups.com. >>>>> 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 jackson-dev...@googlegroups.com. >>>> 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 jackson-dev...@googlegroups.com <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 jackson-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
