Move jackson-datatype-jsr310 into jackson-databind

[pjfanning]

• I have already moved the enable/disable methods for the JavaTimeFeatures to MapperBuilder so they are enabled/disabled similarly to other features
• I have removed the old databind code that warns users when JavaTimeModule is not enabled (no longer needed)
• I have checked that no jackson-datatype-jsr310 code has been missed - including checking for new changes in master branch

@cowtowncoder if you have time, would you be able to review the change from a high level?

• the package structure
• the changes to MapperBuilder and JsonMapper to facilitate registering JavaTImeFeatures and automatically adding the JavaTimeModule serializers/deserializers/etc.

[cowtowncoder]

Good -- I like this idea -- making it work much like modules, without having to be one.

[cowtowncoder]

Looks good so far -- aside from maybe changing package I think this would work.

[cowtowncoder]

LGTM: what do you think @JooHyukKim? (since you are module maintainer)

[JooHyukKim]

@cowtowncoder yes! LGTM at high level.
I like how datetime related classes are isloated in tools.jackson.databind.ext.datetime.
Though my Chrome browser keeps on timing out 😅

Work in progress

@pjfanning you are saying its WIP, may I ask what the remaining pieces are?

[pjfanning]

@cowtowncoder yes! LGTM at high level. I like how datetime related classes are isloated in tools.jackson.databind.ext.datetime. Though my Chrome browser keeps on timing out 😅

Work in progress

@pjfanning you are saying its WIP, may I ask what the remaining pieces are?

I'm happy to treat this as ready to merge at this stage.

[JooHyukKim]

Just one concern I have is how easy it would be to forward merge changes in Jackson 2 version of jsr310 module, good thing is that the module itself does not have frequent changes

[cowtowncoder]

Just one concern I have is how easy it would be to forward merge changes in Jackson 2 version of jsr310 module, good thing is that the module itself does not have frequent changes

That is a valid concern. Not sure we can do a lot about it.
But there will be some fixes in 2.x that need to be ported so at least need to be aware of the extra work.

I feel merging still makes sense, tho, overall. WDYT?

[pjfanning]

I think the JSR310 support is pretty stable. Forward fitting to master (3.0) branches is fairly complicated already. This change doesn't really even make it much more complicated.

[cowtowncoder]

Forward fitting to master (3.0) branches is fairly complicated already.

While there are some kinks to be sure (git seems to lose tracking of some heavily changed renamed classes), overall for modules forward merging has been doable.
But sometimes quite a hassle.

So I agree, it's just a degree of additional complexity. So I think we can live with it.

WDYT @JooHyukKim ?

[JooHyukKim]

LGTM!

[cowtowncoder]

If possible, I think we should actually change the idea here to create new DateTimeFeature that should ideally control ALL date/time handling (mostly concerning then old java.util Date/Calendar and Joda date/time).

It would contain entries we have here, initially, but then see if we could move existing DeserializationFeatures/SerializationFeatures that are date/time specific into this new enum.

This would then be a building block for

https://github.com/FasterXML/jackson-future-ideas/wiki/JSTEP-5

Finally, renamed DateTimeFeature should go in tools.jackson.databind.cfg along with existing EnumFeature and JsonNodeFeature.

[cowtowncoder]

@pjfanning Like I said, this now makes sense.

Had a last minute idea for renaming/repurposing JavaTimeFeature as bit more general DateTimeFeature, to align with idea of JSTEP-5. Nothing too crazy but making it possible to unify some of handling; granted Java (8) Date/Time is the most important part but there is some legacy usage it could help with.

[cowtowncoder]

I think conversion of JavaTimeFeature into ``DateTimeFeature` can (has to) wait after merge: hoping to merge this tomorrow or so.

EDIT: noticed one thing after writing this (see below) -- the way JavaTimeFeature is added needs to change a bit, as there's existing addition point to use (DataTypeFeatures).
I should be able to tackle that tomorrow.

[cowtowncoder]

Ahhhh. Ok, here's something we'll need to change: new JavaTimeFeature (or eventual DateTimeFeature) can and should be added as 3rd thing in DatatypeFeatures (along with EnumFeature and JsonNodeFeature) -- it's designed to be extended.

I can do that tomorrow.

[cowtowncoder]

@pjfanning @JooHyukKim I did last tweaking, renaming and am ready to merge this in. Renamed so that

1. "module" is labelled Java Time (just to align with references I have seen) -- so ext.javatime.*
2. general-purpose on/off features: DateTimeFeature

Beyond merging this big PR I will start filing issues for

1. Moving date/time specific DeserializationFeatures/SerializationFeatures into DateTimeFeature
2. Changing some of feature defaults (one known: 1-based Months; others not yet sure)

and hopefully we can address (most of) these for 3.0.0-rc3.