Prevent unbounded latency converting decimals to time #87
Conversation
This file contains 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
This is to document the current behavior of those conversions.
|
Ok, yes, excellent thank you for the fix! +1 for hiding functionality (I often use I can make that change after merge. Let's see if I can continue discussion on remaining challenge after I merge this. |
# for free
to join this conversation on GitHub.
Already have an account?
# 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.
This change prevents latency explosions when working with high-magnitude
BigDecimalvalues, while preserving the current behavior on the edge cases.It's fixes the original bug reported in FasterXML/jackson-databind#2141 but not the several related issues discussed therein. It builds atop my earlier PR #85
One challenge here is that the current two-step conversion process, using
BigDecimal.longValue()andDecimalUtils. extractNanosecondDecimal()separately, made it hard to control the edge cases because information is lost during the former. So I combined the two into a single helper method.(IMO these helpers shouldn't be public API, since they are bespoke semantics needed by this package, and unlikely to be usable by other contexts. Frankly I'd prefer to make the new helper method package-protected, if that's okay with the maintainers.)