I don't know enough about the limitations between the two libraries. BUT
I would prefer, like Kirk, some consistency w.r.t. implementations.
Also, this is for testing, so I'm really questioning are we going to be
pushing the boundaries of what this library can do. In addition, if
there would be some extra steps that we might have to do, to confirm the
validity of the returned JSON, compared to the native jq implementation,
so be it.
But, maybe the other question we have not yet answered is, what is the
our perception on the lifetime of this implementation. IF we go with the
pure java implementation AND we are so tightly bound to it and they stop
development on it, then we have a whole team of java devs that can take
it over and fix/improve. In the native implementation, this is less
true, so it really becomes a question about, can we maintain it if
necessary.
--Udo
On 9/25/19 4:20 PM, Kirk Lund wrote:
I would prefer we stick to one family of libraries for JSON. So, if there's
a comparable release from Jackson, then I think we should go with that
instead.
On Wed, Sep 25, 2019 at 12:55 PM Owen Nichols <onich...@pivotal.io> wrote:
The Jackson-jq project actually imports the full testsuite from the “real"
jq project, and asks that any discrepancy be reported as a bug. They list
the known differences in great detail…so unless you are using $__loc__ <
https://stedolan.github.io/jq/manual/v1.5/#$__loc__> or date arithmetic
or file I/O in your jq queries, everything else is there.
Since the goal of using jq in tests is really to validate against the
“real” jq that customers would be using, that might be a good argument for
using the native wrapper approach. On the other hand, since Geode's usage
is entirely in tests, switching to another implementation should be easy to
validate, just run the tests. And since the set of JQ inputs is fully
under our control, it wouldn’t be hard to work within the constraints of
the pure-java implementation.
I don’t have a strong opinion on pure-java, just brought this up since Dan
mentioned the concern with introducing native libs. I don’t know if any
Geode developers are running the tests on platforms other than the 3
supported by arakelian (Mac/Windows/Linux).
On Sep 25, 2019, at 10:41 AM, Jinmei Liao <jil...@pivotal.io> wrote:
I did look at jackson-jq before I considered java-jq, but it is a
re-implementation of jq and this statement on that site puts me off:
"jackson-jq
aims to be a compatible jq implementation. However, not all the features
are available; some features are not relevant as being a java library and
some features are just yet to be implemented."
On Wed, Sep 25, 2019 at 9:57 AM Owen Nichols <onich...@pivotal.io>
wrote:
For a pure-java implementation, might be worth considering
https://github.com/eiiches/jackson-jq
On Sep 25, 2019, at 9:40 AM, Dan Smith <dsm...@pivotal.io> wrote:
+1 - sounds good.
BTW - We've previously found libraries that use JNA tend to be more
flaky/platform dependent than pure java libaries - for example we
ripped
out a snappy native wrapper in favor of a pure java implementation.
-Dan
On Wed, Sep 25, 2019 at 8:39 AM Anthony Baker <aba...@pivotal.io>
wrote:
Sounds good, thanks for the heads up.
Anthony
On Sep 25, 2019, at 8:37 AM, Jinmei Liao <jil...@pivotal.io> wrote:
Management rest api wants to add some default jq selector to the
swagger
api docs so that the downstream client tool can use it as a starting
point
to filter/format the json response to a more readable form. In order
to
test these jq selectors, we would like to use a java library
described
here: https://github.com/arakelian/java-jq, it basically provides a
java
wrapper around 'jq' tool. Github shows both MIT and apache license.
We
will
only be using it for testing.
--
Cheers
Jinmei
--
Cheers
Jinmei
