On Tue, Oct 18, 2016 at 6:46 AM, Lovro Pandzic <lovro.pand...@gmail.com> wrote:
> 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. > This is possible, and should be considered. Perhaps coupled with addition of a `MapperFeature` to choose (to allow legacy usage support) this would make sense. > > 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. > Yes, I think this would be good time to align this, and other cases (java.sql.Date) for date/times. And I think there may be couple of other similar cases where datatype modules differ. -+ Tatu +- > > 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> >> 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. >>> 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. > -- 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.
