It might be better to create a Wiki page for Jackson project, although perhaps we could do both: issue(s) for discussion, Wiki page as a draft document of current thinking.
-+ Tatu +- On Tue, Oct 25, 2016 at 7:17 AM, Lovro Pandzic <lovro.pand...@gmail.com> wrote: > Can we formalise all of this in form of github issues? > FYI JSON B public draft (https://java.net/projects/jsonb-spec/pages/Home) > contains some pretty good insight in terms of Java 8 Time/Date/Optional > handling etc. (no parameter names module functionality though). > > On Tuesday, October 18, 2016 at 5:25:49 PM UTC+2, Tatu Saloranta wrote: >> >> On Tue, Oct 18, 2016 at 6:46 AM, Lovro Pandzic <lovro....@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...@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.
