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 <[email protected] > <javascript:>> 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 <[email protected]> >>> 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 < >>>>> [email protected]> 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]> >>>>>> wrote: >>>>>> >>>>>>> On Tue, Oct 4, 2016 at 6:53 PM, Christopher Currie < >>>>>>> [email protected]> 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]> >>>>>>>> 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]. >>>>>>>>> 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. >>>>>>>> >>>>>>> -- >>>>>>> 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. >>>>>>> >>>>>> -- >>>>>> 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. >>>>>> >>>>> >>>>> -- >>>> 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. >>>> >>> >>> -- >> 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.
