Move jackson-datatype-jsr310 into jackson-databind
#5032
Merged
+17,033
−176
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| @@ -0,0 +1,226 @@ | |||
| /* | |||
There was a problem hiding this comment.
Good -- I like this idea -- making it work much like modules, without having to be one.
cowtowncoder
approved these changes
Mar 19, 2025
pjfanning
changed the title
|
LGTM: what do you think @JooHyukKim? (since you are module maintainer) |
|
@cowtowncoder yes! LGTM at high level.
@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
approved these changes
Mar 21, 2025
|
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. I feel merging still makes sense, tho, overall. WDYT? |
|
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. |
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. So I agree, it's just a degree of additional complexity. So I think we can live with it. WDYT @JooHyukKim ? |
| * | ||
| * @since 2.16 | ||
| */ | ||
| public enum JavaTimeFeature implements JacksonFeature |
There was a problem hiding this comment.
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.
|
@pjfanning @JooHyukKim I did last tweaking, renaming and am ready to merge this in. Renamed so that
Beyond merging this big PR I will start filing issues for
and hopefully we can address (most of) these for 3.0.0-rc3. |
cowtowncoder
added a commit
that referenced
this pull request
Apr 4, 2025
This was referenced Apr 5, 2025
cowtowncoder
changed the title
jackson-datatype-jsr310 into jackson-databind
rursprung
added a commit
to rursprung/opensearch-java
that referenced
this pull request
Jun 10, 2025
jackson 2.x still supports java 7 and thus does not automatically support java 8 classes. this will change with jackson 3.x (see e.g. this [PR adding JSR310 date support] to 3.x). PR opensearch-project#251 added documentation on how a custom `ObjectMapper` can be registered - but there's no reason why we can't just enable auto-detection centrally. the docs mention that performance should be considered, but this is IMHO not relevant here since we only construct it once and then keep the same `ObjectMapper` (which in turn the docs mention as best practices). [PR adding JSR310 date support]: FasterXML/jackson-databind#5032
rursprung
added a commit
to rursprung/opensearch-java
that referenced
this pull request
Jun 10, 2025
jackson 2.x still supports java 7 and thus does not automatically support java 8 classes. this will change with jackson 3.x (see e.g. this [PR adding JSR310 date support] to 3.x). PR opensearch-project#251 added documentation on how a custom `ObjectMapper` can be registered - but there's no reason why we can't just enable auto-detection centrally. the docs mention that performance should be considered, but this is IMHO not relevant here since we only construct it once and then keep the same `ObjectMapper` (which in turn the docs mention as best practices). [PR adding JSR310 date support]: FasterXML/jackson-databind#5032
rursprung
added a commit
to rursprung/opensearch-java
that referenced
this pull request
Jun 10, 2025
jackson 2.x still supports java 7 and thus does not automatically support java 8 classes. this will change with jackson 3.x (see e.g. this [PR adding JSR310 date support] to 3.x). PR opensearch-project#251 added documentation on how a custom `ObjectMapper` can be registered - but there's no reason why we can't just enable auto-detection centrally. the docs mention that performance should be considered, but this is IMHO not relevant here since we only construct it once and then keep the same `ObjectMapper` (which in turn the docs mention as best practices). Signed-off-by: Ralph Ursprung <[email protected]> [PR adding JSR310 date support]: FasterXML/jackson-databind#5032
rursprung
added a commit
to rursprung/opensearch-java
that referenced
this pull request
Jun 10, 2025
jackson 2.x still supports java 7 and thus does not automatically support java 8 classes. this will change with jackson 3.x (see e.g. this [PR adding JSR310 date support] to 3.x). PR opensearch-project#251 added documentation on how a custom `ObjectMapper` can be registered - but there's no reason why we can't just enable auto-detection centrally. the docs mention that performance should be considered, but this is IMHO not relevant here since we only construct it once and then keep the same `ObjectMapper` (which in turn the docs mention as best practices). Signed-off-by: Ralph Ursprung <[email protected]> [PR adding JSR310 date support]: FasterXML/jackson-databind#5032
rursprung
added a commit
to rursprung/opensearch-java
that referenced
this pull request
Jun 23, 2025
jackson 2.x still supports java 7 and thus does not automatically support java 8 classes. this will change with jackson 3.x (see e.g. this [PR adding JSR310 date support] to 3.x). PR opensearch-project#251 added documentation on how a custom `ObjectMapper` can be registered - but there's no reason why we can't just enable auto-detection centrally. the docs mention that performance should be considered, but this is IMHO not relevant here since we only construct it once and then keep the same `ObjectMapper` (which in turn the docs mention as best practices). Signed-off-by: Ralph Ursprung <[email protected]> [PR adding JSR310 date support]: FasterXML/jackson-databind#5032
rursprung
added a commit
to rursprung/opensearch-java
that referenced
this pull request
Jun 23, 2025
jackson 2.x still supports java 7 and thus does not automatically support java 8 classes. this will change with jackson 3.x (see e.g. this [PR adding JSR310 date support] to 3.x). PR opensearch-project#251 added documentation on how a custom `ObjectMapper` can be registered - but there's no reason why we can't just enable auto-detection centrally. the docs mention that performance should be considered, but this is IMHO not relevant here since we only construct it once and then keep the same `ObjectMapper` (which in turn the docs mention as best practices). Signed-off-by: Ralph Ursprung <[email protected]> [PR adding JSR310 date support]: FasterXML/jackson-databind#5032
rursprung
added a commit
to rursprung/opensearch-java
that referenced
this pull request
Jun 24, 2025
jackson 2.x still supports java 7 and thus does not automatically support java 8 classes. this will change with jackson 3.x (see e.g. this [PR adding JSR310 date support] to 3.x). PR opensearch-project#251 added documentation on how a custom `ObjectMapper` can be registered - but there's no reason why we can't just enable auto-detection centrally. the docs mention that performance should be considered, but this is IMHO not relevant here since we only construct it once and then keep the same `ObjectMapper` (which in turn the docs mention as best practices). Signed-off-by: Ralph Ursprung <[email protected]> [PR adding JSR310 date support]: FasterXML/jackson-databind#5032
rursprung
added a commit
to rursprung/opensearch-java
that referenced
this pull request
Jun 24, 2025
jackson 2.x still supports java 7 and thus does not automatically support java 8 classes. this will change with jackson 3.x (see e.g. this [PR adding JSR310 date support] to 3.x). PR opensearch-project#251 added documentation on how a custom `ObjectMapper` can be registered - but there's no reason why we can't just enable auto-detection centrally. the docs mention that performance should be considered, but this is IMHO not relevant here since we only construct it once and then keep the same `ObjectMapper` (which in turn the docs mention as best practices). Signed-off-by: Ralph Ursprung <[email protected]> [PR adding JSR310 date support]: FasterXML/jackson-databind#5032
rursprung
added a commit
to rursprung/opensearch-java
that referenced
this pull request
Jun 24, 2025
jackson 2.x still supports java 7 and thus does not automatically support java 8 classes. this will change with jackson 3.x (see e.g. this [PR adding JSR310 date support] to 3.x). PR opensearch-project#251 added documentation on how a custom `ObjectMapper` can be registered - but there's no reason why we can't just enable auto-detection centrally. the docs mention that performance should be considered, but this is IMHO not relevant here since we only construct it once and then keep the same `ObjectMapper` (which in turn the docs mention as best practices). Signed-off-by: Ralph Ursprung <[email protected]> [PR adding JSR310 date support]: FasterXML/jackson-databind#5032
Xtansia
pushed a commit
to opensearch-project/opensearch-java
that referenced
this pull request
Jun 24, 2025
jackson 2.x still supports java 7 and thus does not automatically support java 8 classes. this will change with jackson 3.x (see e.g. this [PR adding JSR310 date support] to 3.x). PR #251 added documentation on how a custom `ObjectMapper` can be registered - but there's no reason why we can't just enable auto-detection centrally. the docs mention that performance should be considered, but this is IMHO not relevant here since we only construct it once and then keep the same `ObjectMapper` (which in turn the docs mention as best practices). Signed-off-by: Ralph Ursprung <[email protected]> [PR adding JSR310 date support]: FasterXML/jackson-databind#5032
opensearch-trigger-bot bot
pushed a commit
to opensearch-project/opensearch-java
that referenced
this pull request
Jun 24, 2025
jackson 2.x still supports java 7 and thus does not automatically support java 8 classes. this will change with jackson 3.x (see e.g. this [PR adding JSR310 date support] to 3.x). PR #251 added documentation on how a custom `ObjectMapper` can be registered - but there's no reason why we can't just enable auto-detection centrally. the docs mention that performance should be considered, but this is IMHO not relevant here since we only construct it once and then keep the same `ObjectMapper` (which in turn the docs mention as best practices). Signed-off-by: Ralph Ursprung <[email protected]> [PR adding JSR310 date support]: FasterXML/jackson-databind#5032 (cherry picked from commit c1ae512) Signed-off-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Xtansia
pushed a commit
to opensearch-project/opensearch-java
that referenced
this pull request
Jun 24, 2025
jackson 2.x still supports java 7 and thus does not automatically support java 8 classes. this will change with jackson 3.x (see e.g. this [PR adding JSR310 date support] to 3.x). PR #251 added documentation on how a custom `ObjectMapper` can be registered - but there's no reason why we can't just enable auto-detection centrally. the docs mention that performance should be considered, but this is IMHO not relevant here since we only construct it once and then keep the same `ObjectMapper` (which in turn the docs mention as best practices). [PR adding JSR310 date support]: FasterXML/jackson-databind#5032 (cherry picked from commit c1ae512) Signed-off-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Xtansia
pushed a commit
to Xtansia/opensearch-java
that referenced
this pull request
Jun 25, 2025
jackson 2.x still supports java 7 and thus does not automatically support java 8 classes. this will change with jackson 3.x (see e.g. this [PR adding JSR310 date support] to 3.x). PR opensearch-project#251 added documentation on how a custom `ObjectMapper` can be registered - but there's no reason why we can't just enable auto-detection centrally. the docs mention that performance should be considered, but this is IMHO not relevant here since we only construct it once and then keep the same `ObjectMapper` (which in turn the docs mention as best practices). Signed-off-by: Ralph Ursprung <[email protected]> [PR adding JSR310 date support]: FasterXML/jackson-databind#5032 (cherry picked from commit c1ae512) Signed-off-by: Thomas Farr <[email protected]>
reta
pushed a commit
to reta/opensearch-java
that referenced
this pull request
Jun 25, 2025
jackson 2.x still supports java 7 and thus does not automatically support java 8 classes. this will change with jackson 3.x (see e.g. this [PR adding JSR310 date support] to 3.x). PR opensearch-project#251 added documentation on how a custom `ObjectMapper` can be registered - but there's no reason why we can't just enable auto-detection centrally. the docs mention that performance should be considered, but this is IMHO not relevant here since we only construct it once and then keep the same `ObjectMapper` (which in turn the docs mention as best practices). Signed-off-by: Ralph Ursprung <[email protected]> [PR adding JSR310 date support]: FasterXML/jackson-databind#5032 (cherry picked from commit c1ae512)
Xtansia
added a commit
to opensearch-project/opensearch-java
that referenced
this pull request
Jun 25, 2025
jackson 2.x still supports java 7 and thus does not automatically support java 8 classes. this will change with jackson 3.x (see e.g. this [PR adding JSR310 date support] to 3.x). PR #251 added documentation on how a custom `ObjectMapper` can be registered - but there's no reason why we can't just enable auto-detection centrally. the docs mention that performance should be considered, but this is IMHO not relevant here since we only construct it once and then keep the same `ObjectMapper` (which in turn the docs mention as best practices). [PR adding JSR310 date support]: FasterXML/jackson-databind#5032 (cherry picked from commit c1ae512) Signed-off-by: Thomas Farr <[email protected]> Co-authored-by: Ralph Ursprung <[email protected]>
001mertiya
pushed a commit
to 001mertiya/opensearch-java
that referenced
this pull request
Jul 9, 2025
jackson 2.x still supports java 7 and thus does not automatically support java 8 classes. this will change with jackson 3.x (see e.g. this [PR adding JSR310 date support] to 3.x). PR opensearch-project#251 added documentation on how a custom `ObjectMapper` can be registered - but there's no reason why we can't just enable auto-detection centrally. the docs mention that performance should be considered, but this is IMHO not relevant here since we only construct it once and then keep the same `ObjectMapper` (which in turn the docs mention as best practices). Signed-off-by: Ralph Ursprung <[email protected]> [PR adding JSR310 date support]: FasterXML/jackson-databind#5032 Signed-off-by: psingh3 <[email protected]>
001mertiya
pushed a commit
to 001mertiya/opensearch-java
that referenced
this pull request
Jul 9, 2025
jackson 2.x still supports java 7 and thus does not automatically support java 8 classes. this will change with jackson 3.x (see e.g. this [PR adding JSR310 date support] to 3.x). PR opensearch-project#251 added documentation on how a custom `ObjectMapper` can be registered - but there's no reason why we can't just enable auto-detection centrally. the docs mention that performance should be considered, but this is IMHO not relevant here since we only construct it once and then keep the same `ObjectMapper` (which in turn the docs mention as best practices). Signed-off-by: Ralph Ursprung <[email protected]> [PR adding JSR310 date support]: FasterXML/jackson-databind#5032 Signed-off-by: psingh3 <[email protected]>
001mertiya
pushed a commit
to 001mertiya/opensearch-java
that referenced
this pull request
Jul 9, 2025
jackson 2.x still supports java 7 and thus does not automatically support java 8 classes. this will change with jackson 3.x (see e.g. this [PR adding JSR310 date support] to 3.x). PR opensearch-project#251 added documentation on how a custom `ObjectMapper` can be registered - but there's no reason why we can't just enable auto-detection centrally. the docs mention that performance should be considered, but this is IMHO not relevant here since we only construct it once and then keep the same `ObjectMapper` (which in turn the docs mention as best practices). Signed-off-by: Ralph Ursprung <[email protected]> [PR adding JSR310 date support]: FasterXML/jackson-databind#5032 Signed-off-by: psingh3 <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@cowtowncoder if you have time, would you be able to review the change from a high level?