* Add support for JSON-P API (JSR 374)
* Add support for JSON-B API (JSR 367)
* Fix Jakarta EE 9 breaking unit tests
* Remove Import-Package instr for JSON-P/JSON-B implementations
* Fix whitespace in unit test classes
* Proxy JSON-P objects and arrays to add mutability
* Update project README for Jakarta JSON providers
Co-authored-by: Leonid Malikov <leonid@percival.co.uk>
* The method getPropertyKeys() in class JsonOrgJsonProvider doesn't check empty jsonObject.
* Addition testcase
* simplify the implementation. And change method names of testcases to something more descriptive
* change names
This was caused when the CompiledPath#invertScannerFunctionRelationship was introduced, effectively in the graph of CompiledPath translating the $..book.length() to $.length($..book) but what it should have done (for length only) is translated it to $.length($..book.*). Rather than make this bugfix in the CompiledPath source code I've made it to the Length source as this shouldn't be an issue for any other routine - length is specific in that its asking about the children (hence the .length() the dot there indicates next node(s)).
This addresses ticket 650 - https://github.com/json-path/JsonPath/issues/650 and adds unit tests for the same.
Co-authored-by: Matt Greenwood <61432137+mgreenwood1-chwy@users.noreply.github.com>
Split ValueNode into a separate class to avoid possible race-condition in class loading.
Modified ArrayPathToken to be super-class of ArrayIndex/ArraySlice token
because IntelliJ warned about null pointer exception possibilities.
Removed redundant boolean checks.
Removed use of StringBuffer -> StringBuilder.
Removed dangling ;
This is a problem in JsonPath where the left-hand side string value was being
quoted by mistake.
Issue 410 on github: https://github.com/json-path/JsonPath/issues/
Also fix issue 409 as well. This should improve performance a bit when parsing.
There are casts because the compiler in IntelliJ was confused as to what overloaded
method to call. Casts don't really hurt.
The fault is in the Parameter object which obviously cached its value and when the outside reference changes its oblivious to that state change due to its internal cached instance of the state. Cache.getCache()... that singleton call inside of JsonContext then grabs an instance of the cached parameter, it would be thread unsafe to simple invalidate the cache because who knows for whom the cache is being invalidated.
Not caching function paths isn't an answer -- the input to a function could itself be another function - meaning the input (parameter) value would never be observed to the wrapping function and things such as take the $.max(3, 4, 5, $.avg(...)) would yield an answer without average being computed.