You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: