Skip to content
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

Think about JSON library update #98

Open
jjg-123 opened this issue Jan 27, 2025 · 1 comment
Open

Think about JSON library update #98

jjg-123 opened this issue Jan 27, 2025 · 1 comment

Comments

@jjg-123
Copy link
Collaborator

jjg-123 commented Jan 27, 2025

The current library used for JSON operations is net.sf.json-lib, which ceased development in 2011 (14 years ago). It even predates javax JSON, AKA json-p support. There is, of course, no JSON support native to Java. It has a few minor vulnerabilities, but the code should not rely on something that has, in effect been orphaned for over a decade. Either use a more modern library like Jackson that has really good benchmark or stick with json-p. The problem with json-p though is that it comes through still as an external dependency (being a javax package) and that means it might just go away if Oracle feels like it. json-lib is so antiquated I can't find anyone benchmarking it, but I suspect it is really slow.

This will be a wide -randing change, so is quite non-trivial, but really has to happen at some point.

Possibly stage it by writing a facade that just fronts net.sf, then swap the implementation. This way we can be done with it once and for all.

@jjg-123
Copy link
Collaborator Author

jjg-123 commented Jan 28, 2025

Looking at a move to Jackson, that relies very heavily on annotations which means either those end up everywhere in the code -- a simply enormous task -- or we have to work out an API that actively works around them. Jackson is made so that JSON (JavaScript Object Notation) lives up to its name of being the main object for data (e.g. beans) in code and annotations allow cross-cutting concerns to be addressed everywhere. We want JSON to be a thing that is supported in QDL, but emphatically do not want it to take over as the main data object. it is a really slick solution for, say, enterprise level AJAX programming.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant