-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use jsonB instead of jackson #586
Conversation
Signed-off-by: Owais Kazi <[email protected]>
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #586 +/- ##
=========================================
Coverage 72.33% 72.33%
Complexity 680 680
=========================================
Files 82 82
Lines 3528 3528
Branches 284 284
=========================================
Hits 2552 2552
Misses 850 850
Partials 126 126 ☔ View full report in Codecov by Sentry. |
s/javax/jakarta/g |
Signed-off-by: Daniel Widdis <[email protected]>
Just wondering from a learning perspective why is jsonB better than jackson? |
https://github.com/search?q=repo%3Aopensearch-project%2FOpenSearch+jackson+cve&type=issues |
i didn't see how many more it had then JsonB :) I assumed any dependency that core is also using we should be okay with but yeah even if core is the one that upgrades, less upstream CVE's from core means less issues cut |
Yeah. I've maintained an open source project since 2015 and it's an annual event to get Jackson CVEs. It's pretty awesome for whole-java-object transformations but if all you need is simple json parsing, it's overkill. The Java client uses JsonB and it used to be part of Java EE, so it just seems like a better choice for simple parsing. |
Tbh here. Jackson supports much more advanced features like polymorphic collection deserialization than jsonB but the question is are we facing any complication because of that? No. Also, as @dbwiddis pointed out the amount of CVEs we have targeted for Jackson is much more than JsonB. Now looking at the performance metrics. Jackson is better than JsonB for serialization and deserialization. I will leave the choice for you all to decide between CVEs and performance. |
It's not just CVEs. Jackson uses reflection to do its magic and there have been concerns there as well: opensearch-project/OpenSearch#5504 We don't need phenomenal cosmic powers to do simple parsing that doesn't need them. :) |
I'm not too concerned about performance here, this is not a hot path thing, just one-time parsing of user-entered JSON values. Is the difference more than a single digit number of milliseconds? |
I found https://github.com/fabienrenaud/java-json-benchmark?tab=readme-ov-file#users-model for the performance of serialization and deserialization of various libraries. I am fine merging this in since we are using jsonB anyway for basic parsing. |
We should use fastjson! 😉 But seriously, looks like our implementation (yasson) is about twice as slow as jackson; 4 microseconds vs. 2 microseconds on average. I can live with that. |
The backport to
To backport manually, run these commands in your terminal: # Navigate to the root of your repository
cd $(git rev-parse --show-toplevel)
# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/flow-framework/backport-2.x 2.x
# Navigate to the new working tree
pushd ../.worktrees/flow-framework/backport-2.x
# Create a new branch
git switch --create backport/backport-586-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 cbf675a12ec869af69fc4405cfc6c9631c425680
# Push it to GitHub
git push --set-upstream origin backport/backport-586-to-2.x
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/flow-framework/backport-2.x Then, create a pull request where the |
* Use jsonB instead of jackson Signed-off-by: Owais Kazi <[email protected]> * Resolve Jar Hell with newest versions and jakarta dependencies Signed-off-by: Daniel Widdis <[email protected]> --------- Signed-off-by: Owais Kazi <[email protected]> Signed-off-by: Daniel Widdis <[email protected]> Co-authored-by: Daniel Widdis <[email protected]>
* Use jsonB instead of jackson (#586) * Use jsonB instead of jackson Signed-off-by: Owais Kazi <[email protected]> * Resolve Jar Hell with newest versions and jakarta dependencies Signed-off-by: Daniel Widdis <[email protected]> --------- Signed-off-by: Owais Kazi <[email protected]> Signed-off-by: Daniel Widdis <[email protected]> Co-authored-by: Daniel Widdis <[email protected]> * Removed 3.x dependency Signed-off-by: owaiskazi19 <[email protected]> --------- Signed-off-by: Owais Kazi <[email protected]> Signed-off-by: Daniel Widdis <[email protected]> Signed-off-by: owaiskazi19 <[email protected]> Co-authored-by: Daniel Widdis <[email protected]>
Description
Based on the discussion on #566. Tried to use
jsonB
fromjakarta
but it's failing with the below upon running the testAfter including the
glassfish
dependencyit failed with jar hell!!
Looking for some idea here.
Issues Resolved
Part of #566
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.